Persistence Manager Issue - Help/Advice Please!

[mstennett]

I?m new to JBoss. I?ve tried to do my research but could use some help.

Currently I?m working on a system that uses queues with the MySQL persistence manager with JBoss 3.2.5. We are currently running into the defect JBAS-1336 URL: http://jira.jboss.com/jira/browse/JBAS-1336. The defect simple states ?When starting up jboss with a destination with either a large number or very large persistent messages, the jdbc pm may run out of memory if the select * from the db results in the jdbc driver pulling in all of the records. We need to either write the pm with this expectation or allow for some configuration to avoid this.? I believe when the system experiences high loads we get a large number of messages persisted. This also occurs when the client receiving the messages can not do so (due to being down).

Apart from making sure a large number of messages don?t get persisted due to load or other reasons (which doesn?t seem like an easy solution). I only see one other solution to use the RollingLogged Persistence Manager. I might loose some old messages but I?m okay with that. The only problem with this is I?ve seen posts that state RollingLogged PM is not reliable and is going away.

Making the messages non-persistence might help the load/performance but if things do get backed up it will still soften the messages to the persistence manager and I will still experience the problem. If I make sure there is a null persistence manager I could blow up the system by running out of memory. Is there a way to have a rollover for non-persistent messages?

I understand that you can set a maximum number of messages on a queue but then it throws an exception the next time the client tries to send another message to the queue. At that point I would have to start queuing the messages at the client. I feel like this defeats the purpose of having the JMS queue.

It looks like currently the only solution is to use Dietmar patch mentioned in the bug post. http://familieposselt.de/jboss-3.2.4RC2-src-patched2.tz.

Is this the only solution? Has this patch been merged into any official version of the code? Is there any other solution to this issue? Can you suggest a better architecture? Is it just that every one uses Oracle or something else that doesn?t have this issue? Or do other systems have a way of guaranteeing that the queues don?t get backed up?

Thanks for any advice.

[gobrien]

I've had problems using the JDBC persistence methods with 3.2.x and used the File Persistence method, its reliable and quite fast (unless you puts 1,000's of messages in the queue, which you can use MaxDepth to restrict the queue size).

The most reliable solution we use is 3.2.3 RMIConnectionFactory and File Persistence Manager (which is not very popular with JBoss), they currently don't support FilePM in 4.0.x.