Tuning JBossMQ

These are just some quick notes on what you might want to do make JBossMQ work better.

The default configuration is pretty unoptimized, but relatively safe in that it works in even the most restrictive of memory settings and with the least capable jdbc drivers.

Threading

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.

Persistence

• JBossMQ uses prepared statements, but by default the DataSource is not configured to do statement caching, so enable it. While you are at it, tune the pool and make it more robust to database errors.

• The default configs that come with JBoss for persistence, see docs/examples/jms are not optimized. You should get your DBA to create the tables manually and analyse your use case to maybe add or change the indexes.

• Hypersonic, don't use it

Memory Usage

• Make sure you change the cache config to match your memory settings, otherwise you are going to be redundantly overflowing messages onto disk when there is still plenty of memory left.

You might also want to disable soft references altogether on the cache if this is giving your garbage collector problems and throttle the softening check using the

SoftenNoMoreOftenThanMillis

Networking

• The main changes are in the buffer sizes. But unless you have lots of large messages this isn't going to make much difference since the buffer is flushed on every request anyway.

• If your messaging clients are co-located with the JBossMQ server (in the same virtual machine) and you aren't using HAJMS, then you should use the in memory connector.

• Even if you are using HAJMS, you should use something like the

  QueueConnectionFactory

  LinkRefPair defined in

  uil2-service.xml

  to automatically optimize away the networking when it is not necessary. This is just a jndi trick.

Antipatterns

Most problems with JMS performance relate to antipatterns. The most common of which is continually opening and closing connections. The spec mentions this. You should pool or cache the connection and use one session per thread.

To make your life easier there is the JMS Resource Adapter inside the appserver. Use it!