activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bruce Snyder" <bruce.sny...@gmail.com>
Subject dilemma with demand-based forwarding
Date Thu, 18 Dec 2008 16:51:50 GMT
I've got a dilemma with demand-based forwarding and how it's handled
in the DemandForwardingBridgeSupport class.

Given a network of brokers using brokerA, brokerB and brokerC, all
networked together in a mesh topology with a networkTTL of 10,
consider the following steps:

1) 100 messages are sent to brokerA
2) Consumer1 connects to brokerB with default prefetch value, consumes
25 messages and disconnects. All messages now reside on brokerB.
3) Consumer2 connects to brokerC with default prefetch value, consumes
25 messages and disconnects. All messages now reside on brokerC.
4) Consumer3 connects to brokerA with default prefetch value, attempts
to consume some messages and receives none. Messages are stuck on
brokerC and cannot be received until a consumer creates a subscription
on brokerC.

In step 4 above, messages are now stuck on brokerC and will not be
forwarded back to brokerA or brokerB because they've already been
routed through those brokers. There's no way for consumers to know
that messages are stuck on brokerC, the messages are effectively stuck
there.

What can be done to mitigate this type of situation?

Bruce
-- 
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'

Apache ActiveMQ - http://activemq.org/
Apache Camel - http://activemq.org/camel/
Apache ServiceMix - http://servicemix.org/

Blog: http://bruceblog.org/

Mime
View raw message