Bug 471302 - Federation: messages statically routed even if there is no consumer at destination [RHEL4]
Summary: Federation: messages statically routed even if there is no consumer at destin...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise MRG
Classification: Red Hat
Component: qpid-cpp
Version: 1.0
Hardware: All
OS: Linux
high
low
Target Milestone: ---
: ---
Assignee: messaging-bugs
QA Contact: Kim van der Riet
URL:
Whiteboard:
Depends On: 442591
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-11-12 21:33 UTC by Justin Ross
Modified: 2009-02-04 16:16 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-02-04 16:16:33 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2009:0038 0 normal SHIPPED_LIVE Red Hat Enterprise MRG Messaging 1.1 Release 2009-02-04 16:16:18 UTC

Description Justin Ross 2008-11-12 21:33:30 UTC
+++ This bug was initially created as a clone of Bug #442591 +++

Description of problem:

In broker federation, routes are completely static.  Messages are routed to
destinations even if there are no bound consumers for the message at the
destination.

Some form of dynamic routing involving the dynamic management of binding keys on
the federation links is needed to provide a valuable/required optimization.

--- Additional comment from gsim on 2008-06-20 04:16:21 EDT ---

*** Bug 446937 has been marked as a duplicate of this bug. ***

--- Additional comment from tross on 2008-10-28 11:17:42 EDT ---

There is a new dynamic-binding feature that addresses this issue.  It can be verified by creating a simple network of two federated brokers.

Here is a shell script to set up the network:

== begin script "setup" ==
broker1=localhost:5672
broker2=localhost:10000

##
## Declare federated direct exchange
##
qpid-config -a $broker1 add exchange direct fed.direct
qpid-config -a $broker2 add exchange direct fed.direct

##
## Create dynamic routes bidirectionally
##
qpid-route dynamic add $broker1 $broker2 fed.direct
qpid-route dynamic add $broker2 $broker1 fed.direct
== end script ==

Note that no binding keys are specified in the creation of the dynamic routes.

The direct example can then be run against the brokers by producing to one broker and consuming from the other.  When the "declare_queues" script is run, it should be run on the consumer broker:

To verify that messages are being forwarded only when needed, use the following Python script:


== begin script "check.py" ==
from qpid.qmfconsole import Session

s = Session()
b = s.addBroker("localhost")

exchanges = s.getObjects(_class="exchange")
for exchange in exchanges:
  if exchange.name == "fed.direct":
    print "Exchange:", exchange.name
    print "received:", exchange.msgReceives
    print "dropped: ", exchange.msgDrops
    print "routed:  ", exchange.msgRoutes

s.delBroker(b)
== end script ==

Here's the procedure for running the test.  Do this in the qpid/cpp/examples/direct directory.

1) Start brokers on the default port (5672) and on port 10000
2) Run the setup script

   $ ./setup

3) Baseline the stats:

   $ python check.py
   Exchange: fed.direct
   received: 0
   dropped:  0
   routed:   0

4) Produce messages:

   $ ./direct_producer localhost 5672 10 fed.direct

5) Check the stats:

   $ python check.py
   Exchange: fed.direct
   received: 11
   dropped:  11
   routed:   0

Verify that the messages were received and dropped (because of no consumer on the other broker).

6) Add a consumer on the other broker:

   $ ./declare_queues localhost 10000 fed.direct

7) Run a listener:

   $ ./listener localhost 10000 &

8) Produce messages again:

   $ ./direct_producer localhost 5672 10 fed.direct
   Message: Message 0
   Message: Message 1
   Message: Message 2
   Message: Message 3
   Message: Message 4
   Message: Message 5
   Message: Message 6
   Message: Message 7
   Message: Message 8
   Message: Message 9
   Message: That's all, folks!
   Shutting down listener for message_queue

Verify that the messages were received by the listener (messages printed above).

9) Check the stats:

   $ python check.py
   Exchange: fed.direct
   received: 22
   dropped:  11
   routed:   11

Verifies that messages were forwarded only when there was an interested consumer.

Comment 2 Frantisek Reznicek 2009-01-06 13:06:42 UTC
bz442591 step-by-step guide finally reproduced and bug validated.
Validated on RHEL 5.2 / 4.7 , i386 / x86_64
->VERIFIED

Comment 4 errata-xmlrpc 2009-02-04 16:16:33 UTC
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-2009-0038.html


Note You need to log in before you can comment on or make changes to this bug.