dilemma with demand-based forwarding

[Bruce Snyder <br...@gmail.com>]

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/

Re: dilemma with demand-based forwarding

[Gary Tully <ga...@gmail.com>]

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 <br...@gmail.com>:
> 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/
>



-- 
http://blog.garytully.com

Open Source SOA
http://FUSESource.com