Moderated: READ THIS FIRST on how to debug this.
This is generally an anti-pattern. Everytime a message is moved from one
queue to another, it is treated as a NEW message.
Everytime you send a message it will be persisted to the persistent store.
Everytime you acknowledge a message it will deleted from the store.
So you generally end up with a system that is spending most of its time
reading and writing the store, rather than doing the business logic.
If you are still using hypersonic (don't) it does not execute queries concurrently.
MDBs are already multi-threaded (15 threads is the default).
Thanks for your response. I am still using the default Hypersonic persistent store, as evidenced by the very large files in $JBOSS_HOME/server/default/data/hypersonic. This is a surprise to me though because I explicitly set the delivery mode in the header of the JMS message to NON_PERSISTENT, which apparently is being ignored by the sender.
The thing that surprises me most is the apparent link between the time taken for the sender.send() to return, and the time it takes for the MDB to process the message consumed as a result of the send. When the individual MDBs processing is quick, then the whole thing works very efficiently, and I can see that by configuring a arbitary number of parallel instances on an SMP host that I get better throughput.
I will try setting up our RDBMS as the persistent store if get better mileage.
Thanks and regards,
Ok - I have read the Wiki, and understand the problem a lot better now. Using the org.jboss.mq.pm.none.PersistenceManager in place of the default JDBC/Hypersonic combination has improved the response of the send() orders of magnitude. We can endure lost messages so this approach might be the best way to go for us.
Apparently this PM does not come bundled with 3.2.3 however, although I managed to obtain the appropriate class files from the 3.2.5 distribution.
I would be interested to know why the Oracle based PM setup does not work (as pe my other thread). I might try the latest 3.2.6 release to see if that resolves the SQLException on a write.
Thanks and regards,