I think the "already routed though" logic is a little harsh. It makes sense on SubscriptionInfo but not on message dispatch. The networkTTL should be used to restrict the amount of rerouting that a network of brokers do as this case shows. I guess with a prefetch of 1, the behavior you describe can be limited to one hidden message, but it cannot be eliminated.
2008/12/18 Bruce Snyder <[email protected]>: > 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)u8...@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/ > -- http://blog.garytully.com Open Source SOA http://FUSESource.com
