activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Tully <>
Subject Re: Options for preferring stability over reliability
Date Thu, 02 Apr 2009 18:58:56 GMT
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 <>

> We are using ActiveMQ quite extensively at 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:
> Sent from the ActiveMQ - User mailing list archive at


Open Source SOA

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message