Why Apache ActiveMQ isn’t good for .NET developers?

September 7, 2009 | by Maciej Greń

Comments

Apache-activemq-logo

Recently, when I had to test some free message queue systems which works with Microsoft .NET I found the list of some interesting systems.  When I found out that Apache ActiveMQ can be also used from .NET, I deiced to test it first. You can see my results below.

A few words about ActiveMQ

Apache ActiveMQ is an open source Enterprise Messaging provider which fully implements the Java Message Service. It provides enterprise features like clustering, multiple message stores, and gives the possibility of using any database such as a JMS persistence provider besides VM, cache, and journal persistence. Apart from these features, it’s very  important that Apache ActiveMQ supports many Cross Language Clients and Protocols, especially C# and .NET. Currently, I’m working on this platform and I’m very glad to have this feature.

The access to ActiveMQ from .NET is provided by Apache .NET Messaging API(NMS). This API allows to build .NET applications in C#, VB, or any other .NET language, using a single API to connect to multiple providers. Currently, ther are also providers for the following messaging systems: ActiveMQ, MSMQ, EBS and STOMP. Of course I use first one.

My issue

I needed a message queue system to solve a specific issue that is presented in the diagram below.

My system with queue

My system with queue

In my system Client 1 needs to send many requests that will be queued. Server application receives and processes a single message quite long time. When processing is complete, the server saves  the processed message and receives the next from a queue, and so on. Client 2 application needs to see what is going on with messages in the system. It acts as a monitoring system. Client 2 has 2 functions. Firstly, it gets a processed messages from the server. Secondly, it checks what messages are waiting in the queue. All messages should be persistent.

I wanted to achieve this using ActiveMQ and Apache NMS. Unfortunately, I couldn’t. I failed.

Why not ActiveMQ?

When I was implementing Client 1 and Server, everything was simple and worked properly. All troubles appeared when I wanted to make function that checks messages in queue. On the diagram above this problem is highlighted in red. I found some examples how to do it, but only in Java. I discovered that I have no access to ActiveMQ Broker service by NMS API. I previewed Java ActiveMQ API and I discovered the reason for this situation: Client and Broker implementations are placed in different packages. Of course this is a good design solution. My way of thinking and expectations were wrong. Yet again I realized that Java applications are created for Java and not for .NET developers.

Conclusion: Although Apache ActiveMQ supports .NET, this feature is limited only to basic client operations. Apache ActiveMQ does not give access to manipulate ActiveMQ broker, persistent store or transports.

Share your opinion and experiences with us below or meet us on Twitter: @GOYELLO.

Thanks to Karol Świder for helping me write this blog post.

  • Eugenis
    Why don't you use Topic instead of Queue? Topic is a Publish-Subscribe structure that is supported in ActiveMQ but not MSMQ.
  • bsnyder
    What has been described above via the diagram is more of a client/server style of design instead of a messaging style of design. Alessios is correct with his suggestion. The proper manner in which to achieve this with messaging is to use asynchronous messaging to handle the event. By simply sending a message to a different queue upon completion of the processing, you're sending another event for which the client can poll. See the following pattern from the EIP book for more info on event messages:

    http://eaipatterns.com/EventMessage.html

    Another way to achieve this from a different point of view is to use request/reply messaging whereby the client sends a request on one queue and receives an asynchronous response on another queue. In your case, the response could be sent after the message processing has completed. The EIP book even has a pattern example of how to achieve this using .NET:

    http://eaipatterns.com/RequestReplyNetExample.html

    Using such patterns will ensure that your system is not only easier for others to understand but will also assist in the proper use of the technology.
  • maciejgren
    Thank you all for your comments. When I was analyzing ActiveMQ I had in my mind 'client/server' style (@bsnyder). Then I was thinking that it just doesn't fit to the way I want to use it. Now I see that by changing the approach I can achieve better effects. What is still important to mention is that due to the bug (@jstrachan) I was not able to implement my solution. That is why I wrote this blog post with hope that you will help me :). Thanks once again.
  • rajdavies
    The 'enhancement' (not a bug) mention by jstrachan is already in ActiveMQ trunk - will make the 5.3 release - due shortly.
  • Alessios
    Just for the sake of curiosity: why don't you send a message on another queue on job completion instead (e.g. one dedicated to the user, if i understand the ratio)? You won't need to poll the queue (activemq handle this for us)
  • jstrachan
    @Alessios - agreed. Thats the 'messaging' way of doing things; which is based on asynchronous message passing and avoids locking yet works in a consistent way despite high concurrency rather than doing non-transactional RPCs (querying queue depths) etc.

    i.e. to use messaging well you don't treat the messaging system as a database to query
  • jstrachan
    NMS should be able to support queue browsing - see http://issues.apache.org/activemq/browse/AMQNET-97

    FWIW you can use the web console to view the queues and browse messages. We're in the process of creating a fully RESTful access to ActiveMQ from any language via http://restmq.fusesource.org/ so any language capable of doing a few HTTP GET requests can find out details on a destination, browse its messages, DELETE them or POST new messages etc.

    In the meantime I've raised this issue which would make it pretty trivial to query the queue size, by just sending a message to a pseudo destination of ActiveMQ.Statistic.Queues.MyQueue and getting back a Map message of the current size & enqueue/dequeue rates etc.

    See https://issues.apache.org/activemq/browse/AMQ-2379
blog comments powered by Disqus