Matthias,<br><br><div class="gmail_quote">2010/2/8 Matthias Radestock <span dir="ltr"><<a href="mailto:matthias@lshift.net">matthias@lshift.net</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
That indicates that the client closed the connection. Or the network died.</blockquote><div>Yep; I also reached that conclusion.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I used to have immediate and mandatory flags set but I've removed<br>
these to make the connection as plain vanilla as possible.<br>
</blockquote>
<br></div>
With these flags set the server may send 'basic.return' commands to the client. Perhaps amqplib doesn't handle these and dies?</blockquote><div>�</div><div>As the problem manifests itself with a plain connection this is not likely to be the cause.�</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im"><br></div>
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.</blockquote>
<div><br></div><div>I've found out�that pika takes the min() of the server-mandated framesize (128k) and the one I specified in the ConnectionParameters()�meaning that I cannot set a larger frame-size.</div><div><br></div>
<div>From reviewing the pika & amqplib code it seems that:</div><div>- pika�takes the header/footer sizes into account when computing the frame-max to use</div><div>- pika actually writes in frame-max blocks, which I don't believe amqplib does. Not sure yet whether this could cause the issue observed.</div>
<div><div><br></div></div><div>When I finish translating my threaded amqplib app into pika using asyncore I hope to find that it solves the problem.�</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br></blockquote></div>
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.</blockquote><div>�</div><div>Tracer writes the full message-body to stdout which isn't helpful when sending multi-megabyte bodies. I'll try using wireshark for diagnostics instead.</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im"><br></div>
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.<br>
<br></blockquote><div>I like the design principles of pika, but the example of demo_relay.py is a little hard going. Can you point me at any other real-world examples of asyncore-based connection handling? And what is the recommended way to detect/handle connection-failure?</div>
<div><br></div><div>Regards,</div><div><br></div><div>Sigurd</div></div><br>