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.


View the original post : 
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880797#3880797

Reply to the post : 
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880797


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
_______________________________________________
JBoss-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jboss-user

Reply via email to