activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <>
Subject Re: ActiveMQ thoughts
Date Mon, 17 Dec 2007 15:11:40 GMT
On 17/12/2007, Nathan Mittler <> wrote:
> Hey James,
> I've captured the details here

Ah great, thanks. Sorry - I was being lazy not reading through all the
previous mails...

> Looks like the C++ producer's response correlator timed out when
> waiting for a response for a sent bytes message (this timeout defaults
> to 3 seconds).
> It may simply be that the app was bogging down the machine (win32) and
> the default timeout wasn't sufficient.

Ah ok - so just increasing the timeout might be a good workaround?

Robert - do you fancy trying that out, setting a big timeout value?

> Is there a flow control that gets imposed on producers that are
> flooding the broker with messages?  If so, could you point me to where
> this is done in the Java client?  It may be that we already have this
> flow control implemented - I know Tim has been working on
> compatibility with the 5.0.0 broker.

He could have sorted it already maybe; it could just be the timeout
issue really.

Here's the command for producer flow control...

which the broker sends producers to inform them that the previous
sending window has been processed, so that they can now send another
window. Its kinda like consumer acks but in reverse. So a nice
producer might wait for a producer ack before sending more data, to
avoid flooding the broker.

You could look at the ActiveMQMessageProducer Java source code to see
how its done.

Though a client can ignore the producer ACKs altogether and the broker
should just stall the transport if it has to for slow consumer

I guess if you know the broker can't accept any more messages, there's
no point trying to send & block; you could maybe give a better
error/log/exception back to the caller?


Open Source Integration

View raw message