[rabbitmq-discuss] Receiving errno 10054 (WSAECONNRESET) writing to queue
matthias at lshift.net
Mon Feb 8 20:53:12 GMT 2010
Sigurd Høgsbro wrote:
> =WARNING REPORT==== 7-Feb-2010::09:56:35 ===
> exception on TCP connection <0.835.5> from 127.0.0.1:47539
That indicates that the client closed the connection. Or the network died.
> I used to have immediate and mandatory flags set but I've removed
> these to make the connection as plain vanilla as possible.
With these flags set the server may send 'basic.return' commands to the
client. Perhaps amqplib doesn't handle these and dies?
> I injected the java Tracer into the path, and spotted a Connection.tune
> method with interesting parameters:
> 1265609050961: conn#0 ch#0 <-
> 1265609051002: conn#0 ch#0 ->
> This led me to the discussion
> on http://www.amqp.org/jira/browse/AMQP-108, suggesting that there is an
> upper limit on AMQP payload of a 16-bit number in versions 0.8/0.9.
That discussion pertains to 0-10 work in progress at the time. In AMQP
0-8/9/9-1 the frame size is encoded in a 32 bit field and the frame-max
field in connection.tune/tune-ok is 32 bit wide too. So the above values
are perfectly fine.
Also note that the frame size does not limit the message size, since
messages can be split across multiple frames. All our supported client
libraries do that automatically but it's possible that amqplib doesn't.
> I'll try patching py-amqplib to take frame-max in kwargs, but any other
> gotchas you can think of would be appreciated?
Try to get a trace that includes the connection disappearance. The
pattern of commands just prior to that might shed some light on what
causes the client to trip up.
> Would I be better off trying Tony's PIKA?
Feel free to give it a try, but since we do not know what the problem is
there is no way to tell in advance whether it will fare any better.
More information about the rabbitmq-discuss