Comparison to ActiveMQ

[obfuscator]

Greetings,

I'm coming from JBoss MQ, which I think lacked a lot in terms of clustering, configuration possibilities and general stability (no smart redelivery retries etc). When I'm now considering an alternative, I look at ActiveMQ which seems to be stable, has a lot of smart features and seems to be production quality. So the question I'm asking myself is: why JBoss Messaging? Could anyone elaborate on why this has been done? I have no experience in ActiveMQ, maybe it just looks better than it is? Licensing issues? Or is this just another not-invented-here thing?

[timfox]

Where do I start with a post like this?

JBM has been around for a few years now, and is a production quality messaging system.

It's the default messaging provider in JBoss EAP and JBoss SOA platforms and JBoss 5.

We're currently working on the next release JBM 2.0, which is due in Q1 2009.

How is it better than ActiveMQ?

1) Better performance. Far better performance with persistent messages. Even in our alpha release we were significantly faster than ActiveMQ: See http://www.jboss.org/file-access/default/members/jbossmessaging/freezone/docs/userguide-2.0.0.alpha1/html/performance.html#performance.results

2) ActiveMQ is just JMS. JBM will support JMS, AMQP and its own core API. It's fully embeddable in your own application as a set of POJOs

3) Highly sophisticated clustering.

4) A host of other features

I'm not really sure why you think ActiveMQ is so great. Sure, it's a fairly reasonable messaging system, but our real competitors, especially with regard to performance are the proprietary systems (i.e. WSMQ, Tibco and Sonic).

We see a lot of people migrating from ActiveMQ to JBM.

Plus you have world beating support from the biggest open source company (Red Hat) in the world backing it. Contrast that with the uncertainty with ActiveMQ after being bought by Progress recently (who already own SonicMQ).

Also have a look at my blog or the project page for more info.

BTW - polite hint - you'd lend yourself more credibility by posting under a name rather than "obfuscator", which clearly implies your hiding your true identity.

[obfuscator]

Dear Tim,

Thank you for your reply. I did not mean to flame you. I just found my question unclear from what I have read, and I was unable to find a quick comparison.

I am a frequent JBoss and Red Hat products user, and my general experience is that the quality is high. But sometimes there are some "not-invented-here" tendencies going on, rewriting libraries because "we can do it better". While this might be true, I feel that it can sometimes hurt other open source projects, and these projects often don't survive in the long run. In terms of being the default for AS and enterprise level, JBoss MQ was also an "enterprise level JMS provider", whatever that means, but it was still largely useless IMHO because of the missing details (DLQ wft, "clustering" using the same db connection etc).

What you bring up here is great and probably obvious to you, but to me it was very unclear. What I am looking for is JMS system which has smarter retry logic than JBoss MQ, is clusterable, transactional and reliable. That is about it. My experience with JBoss Cache is good, so I trust this to be a good way of achieving transactions and clustering. As for the performance, it is not specifically important to my application. A quick google query revealed that JBM retry policies can be set per-destination (which is good), but I got far more hits on ActiveMQ providing the same features, so that raised the question of why someone would like to code the same thing again.

Regarding my name, I can only say that some people have to live with there names being GUID:s, and therefore I am somewhat more careful with my identity. This of course does not mean that I want to hide behind a handle, it's just that I prefer my life not being completely traceable through google.

So thank you for your answers, and please understand that there is a need for quick comparisons for people who don't have experience with every possible JMS provider.

Best regards,

Alexander

[mkelley]

There are a few ActiveMQ features my company is using that I'm wondering about support for in JBM.

- Virtual destinations. See http://activemq.apache.org/virtual-destinations.html. Messages sent to single destination are copied, filtered, and routed to multiple destinations.
- Composite destinations. See http://activemq.apache.org/composite-destinations.html. A comma-separated list of destination names are treated like a single destination.
- Destinations created on demand. See http://activemq.apache.org/how-do-i-create-new-destinations.html. Similar to temporary queues, we have permanent queues that are created on the fly for communication with a remote process. When the process dies, queues are deleted. Unlike temporary queues, messages outlive a JMS session.

Are these among the 'host of other features'? If no, do you have any code/configuration snippets or hints for approximating them (esp. virtual/composite destinations via bridges)?

FWIW the existence of these features in ActiveMQ made it an attractive choice and helped us go pretty far in application development by enabling us to change message routing rules extremely quickly. Now that we know much more about what we want from a messaging system we'd happily trade some features for better scalability, stability, and documentation/support. Knowing more details beyond "a host of other features" would be great start.

Mike

[ataylor]

- Virtual destinations. See http://activemq.apache.org/virtual-destinations.html. Messages sent to single destination are copied, filtered, and routed to multiple destinations.

we don't virtual destinations but we do support wildcard routing in JBM 2.0. i.e. if you send a message to topic.* the message will get routed to topic.A, topic.B etc.

- Composite destinations. See http://activemq.apache.org/composite-destinations.html. A comma-separated list of destination names are treated like a single destination.

no we don't support this at present.

- Destinations created on demand. See http://activemq.apache.org/how-do-i-create-new-destinations.html. Similar to temporary queues, we have permanent queues that are created on the fly for communication with a remote process.

both JBM 1.4 and JBM 2 have a management API for creating destinations on the fly.

If theres anything specific you need feel free to raise a JIRA, we can#t promise to add functionality but if its a value add on it may get done.

[timfox]

"ataylor" wrote:

- Composite destinations. See http://activemq.apache.org/composite-destinations.html. A comma-separated list of destination names are treated like a single destination.

no we don't support this at present.
.

Can't you get the same effect by create multiple queues bound on the same address?

[ataylor]

Can't you get the same effect by create multiple queues bound on the same address?

Tim's correct, in JBM 2 we have the notion of addresses. Every queue is bound to an address so if you bind queue A,B and C to address queueABC, they all recieve any messages routed to that address.

[mkelley]

Thanks guys for the prompt replies. Some followup questions:

we don't virtual destinations but we do support wildcard routing in JBM 2.0. i.e. if you send a message to topic.* the message will get routed to topic.A, topic.B etc.

We don't want to do this. We need to intermix queues (whose listeners MUST receive and process an ordered sequence of messages) and topics (which can be discarded). Even if a topic-only solution was otherwise ok, it would kind of defeat the purpose: having one (or a few) well-known destinations to which all messages could be cc'd, reconfiguring only the broker to filter/route to the right consumers. Using wildcards, we'd wind up spamming all subtopics so that the 'real' topic (say, topic.stock.redhat) and virtual topic (topic.stock) both receive messages.

(WRT composite destinations) no we don't support this at present.

If there's not already in JIRA, shall I go ahead and create one for this?

both JBM 1.4 and JBM 2 have a management API for creating destinations on the fly.

Details, please. A management API so that all subsequent calls to createQueue/createTopic result in actual queue/topic creation? Or a management API that allows us to create destinations if the lookup fails? What's the API?

Tim's correct, in JBM 2 we have the notion of addresses. Every queue is bound to an address so if you bind queue A,B and C to address queueABC, they all recieve any messages routed to that address.

Does this apply to topics as well (and can both destination types be bound to the same address)? Sounds like you're moving toward an AMQP exchange model...?

Mike

[ataylor]

If there's not already in JIRA, shall I go ahead and create one for this?

feel free, but like I say we can't make promises what gets added to releases.

Details, please. A management API so that all subsequent calls to createQueue/createTopic result in actual queue/topic creation? Or a management API that allows us to create destinations if the lookup fails? What's the API?

If you're talking about JBM 1.4 then take a look at the user doc, it describes all the operations available on the JBM mbeans, i.e. queue/topics etc. ( http://www.jboss.org/file-access/default/members/jbossmessaging/freezone/docs/userguide-1.4.1.Beta1/html/index.html ) . If you're talking about JBM 2.0 this is still in development. As theres only an alpha release the best thing to do is to check the code out and take a look at the org.jboss.messaging.core.management packages.

Does this apply to topics as well (and can both destination types be bound to the same address)?

In JBM 2.0 JMS is only a thin client abstraction. At a core level there is only queues. A topic would be an address with multiple queue where each queue has a single consumer. so yes, it can be applied to topics as well.

[timfox]

"mkelley" wrote:


We don't want to do this. We need to intermix queues (whose listeners MUST receive and process an ordered sequence of messages) and topics (which can be discarded). Even if a topic-only solution was otherwise ok, it would kind of defeat the purpose: having one (or a few) well-known destinations to which all messages could be cc'd, reconfiguring only the broker to filter/route to the right consumers. Using wildcards, we'd wind up spamming all subtopics so that the 'real' topic (say, topic.stock.redhat) and virtual topic (topic.stock) both receive messages.

If you can explain in a bit more detail (with a concrete example) in a JIRA we'll see if we can add this to JBM 2.0.

This is something that has come up before, and would be a nice feature to have.

[timfox]

If I understand the requirement correctly, we could add some functionality where you can "link" addresses on the server.

I.e. something like

<address-link>
 <address>myqueueaddress</address>
 <linked-to>mytopic1</address>
 <filter>property1='hello' AND timestamp > 21736276 AND persistent=TRUE</filter>
</address>

Every message sent to adress "myqueueaddress" would automatically also get routed to address "mytopic1".

An optional filter could be provided, using the normal core filter syntax (similar to JMS selectors), so only messages matching the filter would get routed.

Any number of address-links could be specified. This would effectively make up a routing table for messages.

Thoughts?

[timfox]

We could also allow messages to be sent to multiple address (command separated) from the client side like ActiveMQ supports, although I'm not sure this would really be necessary if we specify arbitrary routings on the server side as per my last post.