Bug 681715

Summary: Adding/Deleting Qpid dynamic routes
Product: Red Hat Enterprise MRG Reporter: Nick Capito <ncapito>
Component: python-qpidAssignee: Ken Giusti <kgiusti>
Status: CLOSED DUPLICATE QA Contact: MRG Quality Engineering <mrgqe-bugs>
Severity: high Docs Contact:
Priority: unspecified    
Version: 1.3CC: agoldste, kgiusti, mike.dobozy, tross
Target Milestone: 2.0   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-04-08 18:27:35 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
Test Script none

Description Nick Capito 2011-03-03 00:53:33 UTC
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

Comment 1 Nick Capito 2011-03-03 00:55:06 UTC
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

Comment 2 Nick Capito 2011-03-03 13:28:57 UTC
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/

Comment 3 Mike Dobozy 2011-03-22 15:08:52 UTC
Are there any suggestions on how to work around this issue?

Comment 5 Ken Giusti 2011-03-29 13:11:32 UTC
Upstream JIRA created:


https://issues.apache.org/jira/browse/QPID-3170

working on a potential fix now.

Comment 6 Nick Capito 2011-03-31 13:58:37 UTC
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?

Comment 7 Ken Giusti 2011-03-31 14:31:11 UTC
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!

Comment 8 Nick Capito 2011-03-31 15:30:08 UTC
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

Comment 9 Ken Giusti 2011-04-08 14:30:57 UTC
Fix for add/del route issue pushed upstream:

http://svn.apache.org/viewvc?view=revision&revision=1090266

Comment 10 Ted Ross 2011-04-08 18:27:35 UTC

*** This bug has been marked as a duplicate of bug 690261 ***