Hi Srdhar,
answers inlined:
On 24 Feb 2006, at 19:41, Sridhar Komandur wrote:
Thanks Rob ... I have gone through the link, andcould you please
clarify :
1. when multiple routes exist btw producer and consumer brokers,
are you suggesting
that under 'normal' circumstances duplicates are prevented ? What
circumstances
is it prevented (and which ones result in duplicates ?).
ActiveMQ tags messages with the brokers the message has passed
through - so messages can be filtered out before they are sent to a
broker that message has already visited -
i.e. A -> B -> C -> A (a ring) -
A message originating at broker A - would not be passed from broker C
to broker A (so loops like this are avoided).
However - (excuse the drawing)
B
/ \
A D
\ /
C
A message sent from A to both B and C - B and C both forward to D - D
would get a duplicate of the original.
Now it's possible to filter out duplicates on broker D - by saving a
history of message ids that have passed through broker D - but then
there are a lot of edge cases, especially around re-delivery and
queues - which makes it difficult in practice to do.
2. NetworkConnector 'name' property:
name bridge name of the network - for more than one network
connector between the same two brokers - use different names
example (
Producer-- A- B-C-D ---Consumer
| |
+---E---+
2.1 Does 'name' apply in the above scenario - A and D have multiple
paths, but not direct NetworkConnectors.
No - it only applies to scenarios like this:
->
A B
->
Note the direction (as networks are single plex) - a unique name for
the network would not apply to the usual case for networks:
A <-> B
2.2 How does A route based on 'name', using the above example
(cyclic case) ?
The name is not used for routing - only for creating a unique but
repeatable client ID that is used by the network connector.
3. I would prefer not having to be restricted to acyclic (tree)
graphs, for several reasons:
- more flexibility in routing (e.g., admin reasons)
- single point of failures (I undertand failover tranport will
create NetworkConnector to another broker - but the /flash flood
effects of the distributed system may lead to instability)
- traffic saturation and inability to take advantage of multiple
paths (load balancing)
for different flows.
ok - but hopefully you can use a combination of master/slave and
acyclic networks to get the same solution.
4. I would like to run some preliminary ideas by you offline to
deal with duplicate messages - unless this feature is deemed off
the ActiveMQ roadmap.
If possible - can we keep the discussion on the list - I'm copying to
dev - that way we'll get the benefit of the community input as well :).
Thank you Sir !
Regards
- Sri
Thank you!
cheers,
Rob
On 2/24/06, Rob Davies <[EMAIL PROTECTED]> wrote:
Hi Sridhar,
ActiveMQ does try and prevent sending duplicates - but there are
circumstances where it would be possible for multiple routes across a
network to result in duplicates. I'd advise you to only use acyclic
graphs, or where this can't be avoided, use well named destinations
and network filters.
See http://docs.codehaus.org/display/ACTIVEMQ/Networks+of+Brokers
cheers,
Rob
On 23 Feb 2006, at 22:08, Sridhar Komandur wrote:
> Rob, thanks for your email.
>
> Would you mind clarifying item 1 below, what if there are more than
> one path
> between producer and a consumer for the given networkTTL ?
>
> Will the consumer_broker receive as many messages as the number of
> paths ?
> (I hope not). Could you please elaborate on the details of message
> routing
> in this case ?
>
> Thanks!
> Regards
> - Sridhar
>
> On 2/19/06, Rob Davies <[EMAIL PROTECTED]> wrote:
>>
>>
>> Networks are being updated currently for release 4.0
>> Consumers are propagated around the network - but within
constraints:
>>
>> 1. networkTTL - number of hops (brokers) that this information will
>> pass through - networkTTL also applies to messages dispatched as
well
>> 2. exclusiveDestinations - can exclude destinations from network
>> traffic (can use wild-cards etc)
>> 3. inclusiveDestinations - can specify only destinations which
are in
>> the inclusive list to be propagated around the network
>>
>>
>> I'll update the wiki with this information once we're satisfied its
>> working.
>>
>> cheers,
>>
>> Rob
>>
>> On 13 Feb 2006, at 23:15, Sridhar Komandur wrote:
>>
>>> Hi,
>>>
>>> 1. Can anyone clarify how the routing info is shared within
>>> Network of
>>> Brokers
>>> - is the producer/subscription info known to all the brokers
>>> in the
>>> network ? As I understand,
>>> 4.0 follows demand-forwarding for the actual message flow.
>>>
>>> 2. Has anyone /deployed/thought of/ an architecture where multiple
>>> "Network
>>> of Brokers" clusters would be deployed ?
>>> (not unlike ISP domains, within the same enterprise - for
>>> capacity or
>>> ownership reasons).
>>> I was wondering how "routes" can be selectively disseminated
>>> between
>>> the clusters.
>>>
>>>
>>> Thanks for any insights into the above.
>>>
>>> Thanks
>>> Regards
>>> - Sridhar Komandur
>>
>>
