How broken is the MQ threading model?

[mikemil]

Reading the TuningJBossMQ community wiki page, and wondering how broken is the MQ threading model?  The text in particular is:

Unfortunately, the threading model is pretty broken in JBossMQ. It has been since the original design. If you are having problems too many threads or too much context switching then you should consider JBoss Messaging, it is more performant and more feature rich for other reasons as well.

We may be reaching that 'broken' point with one of our current customers and need to see if we are at the point of recommending a migration from MQ to Messaging (can't go right to HornetQ right now) or of there is just some configuration that we might have set incorrectly.

We are trying to calculate the number of MQ threads required/setup on a server just to handle a local queue with a remote mdb (on another JBoss server).  Digging thru thread dumps, it looks like we get TWO sets of {SocketManager.ReadTask#, SocketManager.WriteTask#, SocketManager.MsgPool} along with a potential Connection Consumer for Subscription thread and a JMS SessionPool Worker thread  - all for one mdb/queue setup.    At worse this looks like 8 threads for each of these on my server.    Does this sound correct?   The confusing part is having TWO complete sets of the ReadTask/WriteTask/MsgPool thread.   I can understand one set of those per server but TWO, which is why I am wondering if we are seeing this correctly?

Both sets of threads seem to be setup and then pinging back and forth every minute as per the configuration.

Our problem is that our configuration has 200 queues on one server with the mdb remote and that same server defines 200 mdbs pointing to remote queues - which if I do the math correctly - with 8 threads per mqb/queue - we are talking about 3200 threads!!!   I hope we have this wrong but just looking for some clarification because if this is basically correct - we don't want to spend any more time trying to get MQ to work and need to quickly get this migrated to Messaging.

Thanks!

[wdfink]

You read old articles, and use a old JBoss version indeed. (I know that this is normal if it works)

JBossMQ will be the old JMS provider of JBoss 4.2.

If you use 4.3 or 5.x you have JBossMessaging by default, which is really better and full cluster aware.

With 6.x or 7.x you will have HornetQ as JMS system.

So as you mentioned in your last sentence I also recommend to use a newer JBoss version with JBM, I would prefere

- latest 5.x if you do not want have big migration efforts

- 7.1 if you will have the latest version, but here 'everything' change (no, not JEE )

[mikemil]

Yes, we have our product implemented with JBoss 4.2.3 using the base MQ for JMS.  The product is a Point of Sale product so we have a JBoss instance at every retail store for a customer.  That along with the current 'holiday season' pushes customers into the "don't touch anything until after Christmas" mode.   Most of the retailers aren't really setup to handle a migration from MQ to Messaging over night, which then leads to issues of how to keep them running and migrate several stores at time.

As developers, we would love to be pushing AS7 and HornetQ but some of these types of deals/customers have a pretty long lead time from initial discussions until final implementation. 

[b.eckenfels]

Yes, the threading model (and transactions, performance and some other aspects) are pretty broken. Trust me, we learned that the same hard way you did

Well... we try to move to HornetMQ and hope it will show, that it does not need to be rewritten at the point we recognize it is broken (thanks god we waited long enough to skip JBM).

A tip for your problem might be to split your one JBoss server into two. For your clients/retailers this will only mean to change the address, of if you want to avoid that as well, you can use a smart loadbalancer (sticky sessions based on source ip hash or something). That way you can half the number of threads (on one server). Since your beans are already remote, this could mean that you replace a 2 mq, n apserver with n+1 appservers+mq-broker (if that is possible).

Greetings

Bernd

[mikemil]

One final comment on this thread.  In one of our customer cases that was failing with MQ and getting OutOfMemoryErrors,  we did find that they (accidently) running the JBoss Native component within our JBoss instance.   We found other postings that using the native component on Windows Server 2003 was 'leaking handles'.   We removed the native folder out from under the bin folder and the handle leaks went away!

They should NOT have been running the native component and luckily, we found that other posting!  While this customers thread count is still pretty high, around 3200 threads at max, they can still run without getting OutOfMemoryErrors after we reduced their MaxPermSize setting from 512m to 256m.