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 )
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.
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).
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.