Thanks for the background Gavin. It's glad to get confirmation that I was on the right track with my understanding.<br><br>A few thoughts:<br><br>It might be worth adding some sort of warning output if there's a synchronous command in the output buffer and then another "method" (e.g., Basic.Publish) get's added.<br>
<br>It would be nice to have some mechanism of saying "Go send whatever output data you have, right now", then wait for some data to arrive back from the server. The incoming data wouldn't have to be processed before returning, but you'd at least know that you could safely send more methods without breaking AMQP rules.<br>
<br>My thinking is that after calling tx_commit() in my message handler, I could call this method.<br><br>Lastly, it would be really helpful to update the Pika doc to reflect what you said in your reply. In particular, this except from the Channel.tx_commit() description appears incorrect, or at least confusing:<br>
<br><i><b>This is a synchronous method that will not allow other commands to be
send to the AMQP broker until it has completed.</b></i><br><br>Thanks again,<br><br>Matt<br><div class="gmail_quote">On Fri, Aug 17, 2012 at 12:38 PM, Gavin M. Roy <span dir="ltr"><<a href="mailto:gmr@meetme.com" target="_blank">gmr@meetme.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br><br><div class="gmail_quote"><div class="im">On Fri, Aug 17, 2012 at 3:13 PM, Matt Pietrek <span dir="ltr"><<a href="mailto:mpietrek@skytap.com" target="_blank">mpietrek@skytap.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I've been drilling into an issue for a few days where my Pika channel is abruptly closed. I'm pretty sure I've found either:<br><ul><li>A large gap in my understanding</li><li>A misuse of the Rabbit/Pika APIs</li>
</ul></blockquote></div><div>Depending on your perspective, this seems the most likely, in that there is not any logic in Pika for managing Tx. It lets you send the RPC calls and leaves it to you to manage state outside of the connection/channel. </div>
<div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><ul>
<li>A serious bug in Pika.</li></ul><p>My original understanding about transactions is that calling tx_select() is a synchronous operation, and that when it returns, whatever actions you've sent to the broker are committed.</p>
<p>However, in stepping through the Pika tx_commit() code, it seems like it all it does is add the Tx.Commit message to an outgoing buffer, and that the tx_commit() call returns without anything actually sent to the broker. (I've set breakpoints in the debugger at strategic points to verify this.)</p>
</blockquote></div><div>This is correct, because pika is event-loop driven, it is putting the frame in the output buffer and returning to you. The event loop will write the data out as the operating system tells it it can You are correct that it is not blocking on the Tx.Commit until the data is written over the socket.</div>
<div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p>In my message handler, I'm writing a reply to the incoming message, using the same channel. What I'm seeing (verified via WireShark) is that the Tx.Commit message is followed by some number of Basic.Publish, Content-Header, and Content-Body records corresponding to my reply message writes.</p>
</blockquote></div><div>Your frames are sent in the order the methods are called. </div><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p> This violates the AMQP standard, which says that nothing should be sent to the broker after sending a Tx.Commit and before receiving a Tx.Commit-Ok reply. (If it helps understanding, my incoming message queue has a few messages in it already, so I see a series of incoming messages immediately after starting.)<br>
</p></blockquote></div><div>You should add a callback for the Tx.Commit-Ok reply and then send your messages. You are correct that Pika is not enforcing the behavior of blocking until Tx.Commit-Ok.</div><div><br></div><div>
You could open a 2nd channel and send your replies over that. </div><div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p>
</p><p>I see that the tx_commit() method takes a callback method, but if I were to simply block in my message handler, waiting for the callback to be invoked, I'd deadlock because Pika's buffer processing code doesn't get a chance to run.<br>
</p></blockquote></div><div>How are you blocking? If you're using any truly blocking method, it will stop the event loop from running. Since you're on the async loop, I'd use a timer and a state variable to toggle between the various states you're trying to achieve.</div>
<span class="HOEnZb"><font color="#888888">
<div><br></div><div>Gavin</div></font></span></div><br>
<br>_______________________________________________<br>
rabbitmq-discuss mailing list<br>
<a href="mailto:rabbitmq-discuss@lists.rabbitmq.com">rabbitmq-discuss@lists.rabbitmq.com</a><br>
<a href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a><br>
<br></blockquote></div><br>