On 17/12/2007, Nathan Mittler <[EMAIL PROTECTED]> 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
