Alan Conway wrote:
In all the cases where I see the failure below, the broker log shows the broker receiving an ExecutionFlushBody *before* the corresponding BasicPublishBody.
There is a loop in this test; could the apparently preceding flush be from the earlier loop?
On another note there are actually two flushes sent in this test per publish. As the channel is in synchronous mode the peer sends one itself (should be a synch now, that wasn't implemented when this was started). The explicit flush is no no longer necessary. However thats not the cause of the failure I don't think.
Is there any way the python client could be re-ordering these methods? Is there any way the brokers AsynchIOAcceptor could be delivering these methods out of order?
I think this is unlikely. Its more likely to be a subtle race in the broker or client that is somehow occasionally getting the command completion confused.
I can't actually reproduce the issue... If you have a broker log I can have a look at it.
