<div>
                    <br>
                </div>
                <div></div>
                 
                <p style="color: #A0A0A8;">On Thursday, June 6, 2013 at 3:05 AM, Matthias Radestock wrote:</p>
                <blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;">
                    <span><div>Having to lengthen the interval artificially - e.g. so that</div><div>single-threaded clients can process a whole message - conflicts with </div><div>that. More generally, client libraries / applications should be </div><div>responsive to incoming AMQP traffic. I don't know enough about pika and </div><div>python threading to ascertain whether there is a convenient way to </div><div>achieve that.</div></span></blockquote><div>Currently it is single threaded. I have a few prototypes of running all connection management in a background thread, but this is tricky due to Pika supporting pluggable backend connection adapters. What's good for a blocking connection adapter in doing threaded connection communication is not good for asynchronous adapters such as Tornado and Twisted.</div><div><br>
                </div><div>Regards,</div><div><br></div><div>Gavin</div>