Hide Forgot
Created attachment 488499 [details] Simple python client Description of problem: When you declare an exchange and associate an alternate-exchange, functionality will cease if a client abruptly disconnects. In other words the exchange will not forward orphaned messages for any routing-key that was associated to a client that did not gracefully disconnect. How reproducible: 1. Create a broker 2. Create an Exchange with an alternate exchange 3. Drain on Alternate Exchange 4. Spout message to Exchange/Test.Key (you will see it) 5. Create a python client on Exchange/Test.Key (provided below) 6. Spout message to Exchange/Test.Key (will see it in client) 7. Abruptly disconnect client ctrl+c (do not clean up) 8. Spout message Exchange/Test.Key( you will not see it in failure exchange drain) Steps to Reproduce: 1. qpid-config add exchange topic "Failure" 2. qpid-config add exchange topic TestExchange --alternate-exchange="Failure" 3. ./drain -f -b localhost:5672 "Failure" 4. ./spout -b localhost:5672 "TestExchange/Test.Key" "Will see in faulure exchange drain" 5. Launch client provided: python simple_client.py Test.Key 6. ./spout -b localhost:5672 "TestExchange/Test.Key" "Will not see in failure exchange drain" 7. Client will display message 8. Ctrl+C client 9. ./spout -b localhost:5672 "TestExchange/Test.Key" "Will not see in faulure exchange drain" 10. Will not see the message in failure exchange Additional info: If you gracefully disconnect functionality works as expected. If you pass an additional parameter to the simple_client it will disconnect gracefully Steps to Reproduce((notice we are changing the key to Test2.Key): 1. ./drain -f -b localhost:5672 "Failure" 2. ./spout -b localhost:5672 "TestExchange/Test2.Key" "Will see in faulure exchange drain" 3. Launch client provided : python simple_client.py Test2.Key graceful 4. ./spout -b localhost:5672 "TestExchange/Test2.Key" "Will not see in failure exchange drain" 5. Client will display message 6. Ctrl+C client 7. ./spout -b localhost:5672 "TestExchange/Test2.Key" "will see in failure" Works as expected.
This is because with the python client the temp subscription queue is created as non-auto-deleted by default. On clean shutdown the queue is deleted, but on non-clean/abrupt shutdown (e.g. failure condition), the queue remains and thus there is a matching binding and subsequent messages go to that queue rather than the alternate-exchange. If you set the reliability to be unreliable explicitly you get the expected behaviour in this case e.g. receiver = connection.session().receiver("TestExchange/%s; {link:{reliability:unreliable}}" % key)
See https://bugzilla.redhat.com/show_bug.cgi?id=693444 for the inconsistency issue.