Hide Forgot
Description of problem: Ran into an issue today with qpid-route dynamic add/del . Just to give you an idea of what we are trying to accomplish we have 4 brokers all using the same exchange. I left it out of the explination below to keep it simple. All of the routes are added via qpid-route. src->dest represents a qpid-route. The arrow represents the direction of the route. Scenerio: Broker 1 -> Static Route: 'Out.Key' -> Broker A Broker 1 <- Static Route: '#.Key' <- Broker A Broker A <= Dynamic Route => Broker B (Both ways) Broker 2 -> Static Route: 'Out.Key' -> Broker B Broker 2 <- Static Route: '#.Key' <- Broker B Our map really looks like this with the caveat that the static is really two separate keys one being #.Key the other Out.Key Broker 1 <=Static=> Broker A<=Dynamic=> Broker B <=Static=> Broker 2 On first time creating the Dynamic link betweek Broker A and Broker B it works perfectly. Send Message(Out.Key) -> Broker 1 <=Static=> Broker A<=Dynamic=> Broker B<=Static=> Broker 2 -> (Message Received) If we delete both sides of the dynamic route and re add them then the following fails: Send Message(Out.Key) -> Broker 1 <=Static=> Broker A<=Dynamic=> Broker B<=Static=> Broker 2 -> (Message Failed) What we have found is that the message will make it all they way to Broker B, but will never follow the static route to Broker2. We have also found that if we drain on Broker B, it will then propagate to Broker 2. It is reproduceable Steps to Reproduce: 1. Create 4 Brokers 2. Run these commands: qpid-route route add localhost:5671 localhost:5673 ExchangeName "#.Key" qpid-route route add localhost:5673 localhost:5671 ExchangeName "Out.Key" qpid-route route add localhost:5675 localhost:5674 ExchangeName "#.Key" qpid-route route add localhost:5674 localhost:5675 ExchangeName "Out.Key" qpid-route dynamic add localhost:5673 localhost:5674 ExchangeName qpid-route dynamic add localhost:5674 localhost:5673 ExchangeName #everything below this will cause the federation to break #before these lines everything works perfectly qpid-route dynamic del localhost:5673 localhost:5674 ExchangeName qpid-route dynamic del localhost:5674 localhost:5673 ExchangeName qpid-route dynamic add localhost:5673 localhost:5674 ExchangeName qpid-route dynamic add localhost:5674 localhost:5673 ExchangeName 3. Create Receiver: ./drain -b localhost:5675 "ExchangeName/Out.Key" "Test" 3. Send message ./spout -b localhost:5671 "ExchangeName/Out.Key" "Test" Actual results: Noting, will make it to 5674 or 5673 but never to 5675 or 5671. Expected results: Messages to arrive at 5675 or 5671 Additional info: We have found that if you add a drain to 5674 or 5675 will make the messages arrive at 5675 or 5671. The first time you test, do not run
Just so you all know the mapping above is Broker 1 = localhost:5671 Broker A = localhost:5673 Broker B = localhost:5674 Broker 2 = localhostZ:5675
Created attachment 482080 [details] Test Script This script will setup the necessary federation in order to test the bug. It will create 4 brokers 5671,5672,5673,5674 and will federate them. At the end of the run all you need to do is run the spout/drain commands, show it works. Then kill the drain and run the lines that delete the dynamic route and add them back. Run the drain/spout and it will not work. To clean up kill the brokers and delete the tmp directory /home/bug/
Are there any suggestions on how to work around this issue?
Upstream JIRA created: https://issues.apache.org/jira/browse/QPID-3170 working on a potential fix now.
I was able to test out the patch provided above and we can now delete/re add dynamic routes. 2 additional comments/questions. 1. Do you know why I had to fix some casting errors in the following files: /qpid/cpp/bindings/qmf/python/qmfengine.cpp (2051, 17069) /qpid/cpp/bindings/qpid/python/cqpid.cpp (2051, 11402) /qpid/cpp/bindings/qmf2/python/cqmf2.cpp(2051, 16534) My solution was to add a const_cast<char *> around them and they all involved a ml_doc instance. 2. Do you know if this bug is related to an issue we were seeing when we shutdown a broker (qpidd --quit), then restarted and the dynamic routes no longer worked?
Hi Nick, Q1: To be honest - I can't answer that. Those files are automatically generated by the "swig" program, using the C++ api as input. So the content of these files can vary between version of swig, and even python. Even the version of the GCC toolchain may factor in here. For example, I'm running F14 latest with swig-2.0.1-1.fc14.x86_64 python-2.7-8.fc14.1.x86_64 gcc-4.5.1-4.fc14.x86_64 and these files compile cleanly on my system. However, this should be investigated - can you open a BZ against MRG, component "management", and attach those files as-generated on your system. Also list the versions of swig/python/gcc, etc you are using. Thanks. (btw - these files should not be affected by the changes for this federation bug. This problem is unrelated.). Q2: Possibly - if you restart one broker in the federation, and that broker shares a binding key that is identical to a binding on another broker in the federation (eg. "#.Key" bound on both brokers). But without reproducing the setup, I cannot say for sure. Thanks for testing out the patch!
No problem, thanks for fixing it. Here is the link the other bug I think is related: https://bugzilla.redhat.com/show_bug.cgi?id=690261
Fix for add/del route issue pushed upstream: http://svn.apache.org/viewvc?view=revision&revision=1090266
*** This bug has been marked as a duplicate of bug 690261 ***