activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Davies <>
Subject Re: Blocking on UsageManager.waitForSpace again
Date Mon, 22 Jan 2007 23:08:13 GMT
Hi Albert,

a junit test case to reproduce this will really help speed up a  
resolution :)


On 22 Jan 2007, at 20:10, Albert Strasheim wrote:

> Hello all
> On Mon, 22 Jan 2007, James Strachan wrote:
>> FWIW I"d definitely recommend you use non-persistent sending on your
>> producers (otherwise the spool to disk won't kick in). Also are you
>> actually ack'ing your messages?
> First off, we're using ActiveMQ 4.2 from trunk.
> I've taken a closer look at our application and I think I'm  
> beginning to
> understand what's going on.
> We have a non-persistent producer sending to a non-durable consumer
> through a topic. Sessions are set to auto-acknowledge We're seeing
> issues when running our test code, which uses an embedded broker,  
> but I
> think these issues will also crop up with a separate broker.
> The producer is sending relatively large messages (1--2 kB) as fast as
> the data they contain can be read from disk. The consumer  
> subscribed to
> the topic does a lot of processing on these messages (i.e. the
> consumer is slow) before sending a few smaller messages to another
> topic. What usually happens is that this send blocks, due to
> MemoryUsagePercent being 100. Since the consumer blocks while  
> trying to
> send the small message, it no longer consumes any of the large  
> messages
> and our application stops.
> The same thing happens even when the consumer simply consumes the  
> large
> message and puts it into a Java queue serviced by another thread. The
> rapidly produced big messages fill up the broker's memory, causing the
> thread to block when trying to send a small message after taking a big
> message from the queue.
> In our case, we definately don't want to drop messages if the consumer
> can't keep up. Instead, we want the the fast producer to block,  
> without
> using up all the broker's resources, preventing the slow consumers  
> from
> actually handling the messages they receive (which involves sending
> another message).
> I seem to recall that I read somewhere in the mailing list archives or
> in one of the JIRA issues about a per-destination buffer. It seems  
> like
> this would solve our problem: as long as there's a bit of space for  
> the
> slow consumers to send out their messages, they can keep going and the
> producer can send new big messages as space becomes available.
> Should this be happening already? Are we doing something wrong?
> Any comments appreciated.
> Cheers,
> Albert

View raw message