Bug 690261
| Summary: | Broker Federation broken after QPIDD restart | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise MRG | Reporter: | Nick Capito <ncapito> | ||||
| Component: | qpid-qmf | Assignee: | Ken Giusti <kgiusti> | ||||
| Status: | CLOSED ERRATA | QA Contact: | ppecka <ppecka> | ||||
| Severity: | high | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 1.3 | CC: | freznice, iboverma, jneedle, kgiusti, ppecka, tross | ||||
| Target Milestone: | 2.0 | ||||||
| Target Release: | --- | ||||||
| Hardware: | i686 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | qpid-cpp-mrg-0.10-4 | Doc Type: | Bug Fix | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2011-06-23 15:43:37 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
Proposed patch at https://reviews.apache.org/r/557 This is likely related to Bug 681715 *** Bug 681715 has been marked as a duplicate of this bug. *** Merged to mrg_2.0.x: http://mrg1.lab.bos.redhat.com/git/?p=qpid.git;a=commitdiff;h=4e78a53480efc32bd4ec94fdbc4df0ad0ba05b94 VERIFIED on rhel5.6 / rhel 6.1 - i686 / x86_64: qpid-java-client-0.10-6.el6.noarch qpid-cpp-client-0.10-5.el6.i686 qpid-cpp-client-devel-0.10-5.el6.i686 qpid-tools-0.10-4.el6.noarch qpid-cpp-server-rdma-0.10-5.el6.i686 rh-qpid-cpp-tests-0.10-5.el6.i686 qpid-java-common-0.10-6.el6.noarch qpid-java-jca-0.10-6.el6.noarch qpid-qmf-0.10-7.el6.i686 qpid-cpp-client-ssl-0.10-5.el6.i686 qpid-cpp-server-ssl-0.10-5.el6.i686 qpid-cpp-server-store-0.10-5.el6.i686 qpid-cpp-server-0.10-5.el6.i686 qpid-cpp-client-rdma-0.10-5.el6.i686 qpid-cpp-server-devel-0.10-5.el6.i686 qpid-cpp-server-xml-0.10-5.el6.i686 python-qpid-0.10-1.el6.noarch qpid-java-example-0.10-6.el6.noarch qpid-cpp-client-devel-docs-0.10-5.el6.noarch python-qpid-qmf-0.10-7.el6.i686 qpid-qmf-devel-0.10-7.el6.i686 ruby-qpid-qmf-0.10-7.el6.i686 qpid-cpp-server-cluster-0.10-5.el6.i686 --> VERIFIED qpid-tests-0.10-1.el6.noarch An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHEA-2011-0890.html |
Created attachment 487105 [details] Script to reproduce bug. Description of problem: Scenerio is as follows: Four brokers BrokerA1 : (5671 in script) BrokerA2 : (5672 in script) BrokerB1 : (6671 in script) BrokerAB2: (6672 in script) The federation is as follows qpid-route -d route add localhost:5671 localhost:5672 Bug '#.Key' qpid-route -d route add localhost:5672 localhost:5671 Bug '#.A.Key' qpid-route -d route add localhost:5672 localhost:5671 Bug '#.Other.Key' qpid-route -d route add localhost:6671 localhost:6672 Bug '#.Key' qpid-route -d route add localhost:6672 localhost:6671 Bug '#.B.Key' qpid-route -d route add localhost:6672 localhost:6671 Bug '#.Other.Key' BrokerA1->#.A.Key->BrokerA2 BrokerA1->#.Other.Key->BrokerA2 BrokerA1 <-#.Key <-BrokerA2 BrokerB1->#.B.Key->BrokerB2 BrokerB1->#.Other.Key->BrokerB2 BrokerB1 <-#.Key <-BrokerB2 Then the BrokerA1 and BrokerB1 are dynamically linked BrokerA1 <=> BrokerB1 The general flow is as follows: Message(subject=B.Key) -> BrokerA2 -> BrokerA1 -> BrokerB1 -> BrokerB2 received Message(subject=Other.Key) -> BrokerA2 -> BrokerA1 -> BrokerB1 -> BrokerB2(received) Everything works perfectly, can send messages back and forth by pushing messages to brokers A2 or B2, the messages will arive on the opposite node. So I put a message (with key A.Key or Other.Key) on A2, I can receive it on B2, and vice versa. If I then terminate broker A1, wait any period of time and restart broker A1, wait any amount of time, and re run the above #.Key link works, but Other.Key does not. My assumption is if the Static keys are the same, when the federation restarts it does not create the nessessary bindings if there is exists a route with the same name. Additional info: Once I put a drain on B1, things start working.