activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hellweek <bwins...@tfutures.com>
Subject Re: ActiveMQ thoughts
Date Tue, 18 Dec 2007 13:34:22 GMT

Yes please tell me where to change the code for th etime out I will re
compile and try.

James.Strachan wrote:
> 
> On 17/12/2007, Nathan Mittler <nathan.mittler@gmail.com> wrote:
>> Hey James,
>> I've captured the details here
>> http://issues.apache.org/activemq/browse/AMQCPP-157
> 
> 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...
> http://activemq.apache.org/maven/activemq-core/apidocs/org/apache/activemq/command/ProducerAck.html
> 
> 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
> handling.
> 
> 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?
> 
> -- 
> James
> -------
> http://macstrac.blogspot.com/
> 
> Open Source Integration
> http://open.iona.com
> 
> 

-- 
View this message in context: http://www.nabble.com/ActiveMQ-thoughts-tp14262131s2354p14396837.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.


Mime
View raw message