please post as much information as you can w.r.t number of topics, queues and xml configuration. If you can produce a junit test case that demonstrates the behaviour you are experiencing that would be fantastic.
Using systemUsage it should be possible to ensure memory is never exhausted and messages are spooled to temp storage on disk. An alternative strategy is to enable sendFailIfNoSpace on systemUsage which will ensure that there is no sender block when a usage limit is reached. Flow control needs to be enabled to make use of this feature and you producers will need to handle the JMSException that may be thrown. What version are you using? 2009/4/2 MassDosage <massdos...@gmail.com> > > We are using ActiveMQ quite extensively at Last.fm and are experiencing a > number of issues related to the huge load we are putting on it (at peak > times up to thousands of messages per second). We are using it in a number > of different scenarios but our general use case is that we would much > rather > lose hundreds of messages than have deadlocks, out of memory errors and > crashes. > > We have turned off producer flow control, set persistence to false, are > using async send, short expiry times on messages etc. Even with this setup > we still regularly (several times per week) run into instances where > ActiveMQ completely fails us - ranging from Out of Memory Exceptions in the > server to blocked Senders to the entire system locking up/freezing with > nothing useful in the log files. These situations force us to restart the > ActiveMQ server regularly and have brought the affected part of our service > to their knees. Ideally this would never happen and in times of heavy load > Senders would not block but instead would drop messages and the server > would > do the same instead of running out of memory. Are we missing some > configuration/API options we can use to ensure this behaviour? Does anyone > have any suggestions? I am happy to post our activemq.xml and code samples > if necessary. > > I can understand that many of your use cases require reliability and that > you have built much of the system to ensure as few messages get dropped as > possible but we really want the opposite - a system that never goes down or > causes deadlocks and we are willing to lose as many messages as it takes to > allow for this. > > -- > View this message in context: > http://www.nabble.com/Options-for-preferring-stability-over-reliability-tp22852174p22852174.html > Sent from the ActiveMQ - User mailing list archive at Nabble.com. > > -- http://blog.garytully.com Open Source SOA http://FUSESource.com
