I have been looking at the implementation of JMS queues in JBoss 3.0.7 and I have some concerns.
I am implementing an application that gets a huge number of messages inserted on a JMS queue, reads off the queue and processes the messages.
It seems strange to me to implement the MessageCache and PersistenceManagers as two seperate modules. If I would be implementing a "special" JMS queue for my application I would have this as one module that simply has some small cache of the messages first on queue, and the rest persisted.
In the current model all messages get persisted and are then put to the message cache, and if that get's too big it is persisted to a file, so in effect messages are persisted twice.
This also makes the JBoss startup extremely slow if the queue contains a lot of messages since all messages are read from the persistence manager, are then subsequently put to the Message Cache that ends up persisting the messages again!
Do you agree with me that this implementation has some shortcomings, or am I missing some important detail?
Anyway...we found out that we could not use the file-based managers because the operating system could not handle the amount of files. Note that even though the RollingFilePersistanceManager uses a single file for the queue, the MessageCache uses a single file for each message!
We started using the JDBC2 persistance manager, but found out that it uses the same MessageCache implementation by default. Then I noticed that the JDBC2 PersistanceManager class actually implements the MessageCache interface, so I changed the configuration so that the JDBc2 persistance manager uses itself as a message cache. Is that something that is all right? I haven't seen anything in the JBoss documentation that supports this option?
Anyway we are slowly building up expirence with JBoss and as we learn more it gets better.
By the way... I really like the coding style and design of JBoss although I have some doubts concerning the JMS part ;)
Halldor Isak Gylfason