You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@activemq.apache.org by Sridhar2008 <ac...@komandur.com> on 2008/05/14 02:27:18 UTC

Cluster transport ...

Hi,

I'm working on a feature needed for our internal use for a highly available
messaging bus service. Per James, I am capturing a short description of our
needs. I would appreciate any feedback, for the larger activemq user
community usage ...

+----B1 ---+
| |
P---+---B2-----+---- C
| |
+---B3-----+

We'd like producers/consumers to be connected to multiple brokers
simultaneously for high availability - we have had outages due to single
broker failure and we also the desire seamless in/out of servicing brokers
as needed or based on jmx monitoring. In addition, producers and consumers
will not be hardcoded with specific broker addresses. They will have the
broker cluster 'cname' which is resolved as 'service record' in the DNS ---
so we will also be contributing a new DNS based discovery module. This
facilitates dynamic addition/removal of brokers as needed for : capacity,
availability, etc. The producer will send to all the available brokers
(perhaps round robin) and consumers will accept from all the available
brokers.

This is the basic premise of the feature. This can be enhanced in various
ways. For example, to take a broker out of service, I plan on configuring
through the jmx, so the broker will stop accepting new messages, while the
consumers are draining existing messages. Once the messages are drained, it
will shut itself down. Another possible enhancement is to load balance
messages among the brokers.

Thanks,
Regards,
- Sridhar Komandur
--
View this message in context: http://www.nabble.com/Cluster-transport-...-tp17221068s2354p17221068.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.

Re: Cluster transport ...

Posted by Hiram Chirino <hi...@hiramchirino.com>.

On Thu, May 22, 2008 at 8:58 PM, Sridhar2008 <ac...@komandur.com> wrote:
>
>
> James:
>
> As you noted, the purge delay is not that big of a deal.
>
> The case of  'cluster bootup' where there weren't any to begin with is a
> legitimate use case. Again, how fast new  entries traverse from master to
> slave DNS depends on implementation - for example, the refresh could be
> quicker when there is a change.
>
> Depending on how big a deal this use case is, there could be other options:
> when a cluster name can't be resolved,  the discovery plugin can be
> configured to go to a 'seed server' (which could be slower) and which
> directly queries db or another possibility is for the 'name' to actually
> resolve this 'seed server' cluster - which in essence is a distributed
> membership service.
>
> Hiram:
>
> Perhaps you referring to nscd caching ?, otherwise I am not clear how a
> client can influence slave-dns server behavior. We should probably defer any
> non-standard tricks.
>

I'm just talking about a way to avoid needing to set a short refresh
on DNS records.  One way is to keep the client querying different host
names that map to the same record.

> Thanks,
> Regards,
> - Sridhar Komandur
>
>
> Hiram Chirino wrote:
>>
>> On Tue, May 20, 2008 at 4:13 AM, James Strachan
>> <ja...@gmail.com> wrote:
>>> I'm not much of an expert in the behaviour of DNS servers :) so I
>>> thought I'd think aloud a little...
>>>
>>> I guess we don't really care too much about old broker entries in DNS;
>>> if a client can't connect it just tries the next one it finds - so its
>>> really just an optimisation; a good DNS server would zap them quickly
>>> but even if they stick around for 24 hours its not that big a deal as
>>> there's hopefully not gonna be loads of brokers being started/stopped
>>> on random IP addresses or anything :)
>>>
>>> The thing I'm pondering is if folks boot up a new broker on a new box,
>>> we want clients to be able to find it pretty soon. In most DNS servers
>>> you've worked with before - if you add a new entry (rather than
>>> entries expiring) do servers tend to reflect that quickly to clients?
>>> I can imagine in a highly federated DNS server network it might take a
>>> while to propogate. Just wondered :)
>>>
>>
>> You could work around that with a smart client and DNS server.  Lets say
>> that
>>
>> cluster-a.mynetwork.com is hostname for the cluster.  If we want to
>> avoid DNS caching of it's DNS records by my local DNS server, then the
>> client could lookup ${timestamp}.cluster-a.mynetwork.com.  Basically
>> change out the cache key.
>>
>> Now, the DNS server admins might not like this usage pattern much so
>> perhaps it's best to keep it optional.
>>
>>
>>> 2008/5/19 Sridhar2008 <ac...@komandur.com>:
>>>>
>>>>>Agreed.
>>>>>
>>>>>We've got a pluggable discovery mechanism; both for the broker >to
>>>>>advertise itself or for brokers/clients to discover things, so I >guess
>>>>>DNS just becomes another provider.
>>>>>http://activemq.apache.org/discovery.html
>>>>
>>>> Exactly ! The pluggable nature of ActiveMQ is great for enhancements
>>>> like
>>>> these.
>>>>
>>>>>The difference with DNS is you may use your existing DNS >provider or
>>>>>might wanna run a custom implementation to get the timeout >stuff etc?
>>>>
>>>> Again, right on ! The timeout may not be that big a deal depending on
>>>> the
>>>> implementation ... for example, it might be a lazy cleanup process which
>>>> may
>>>> or may not be part of the DNS master server. For the clients (ie
>>>> producers
>>>> or consumers), if a broker in the list does not respond, it will just
>>>> timeout to the next (note: 'next' could be as simple as next in the list
>>>> or
>>>> based on some policy).
>>>>
>>>>
>>>> James.Strachan wrote:
>>>>>
>>>>> Agreed.
>>>>>
>>>>> We've got a pluggable discovery mechanism; both for the broker to
>>>>> advertise itself or for brokers/clients to discover things, so I guess
>>>>> DNS just becomes another provider.
>>>>> http://activemq.apache.org/discovery.html
>>>>>
>>>>> The difference with DNS is you may use your existing DNS provider or
>>>>> might wanna run a custom implementation to get the timeout stuff etc?
>>>>>
>>>>> 2008/5/19 Sridhar2008 <ac...@komandur.com>:
>>>>>>
>>>>>>
>>>>>> Thanks for the link. I quickly glanced through the dnsjava website,
>>>>>> and
>>>>>> not
>>>>>> clear if it requires a specific server for updates to work.
>>>>>>
>>>>>> Also, most large organizations have their own legacy DNS in place,
>>>>>> with
>>>>>> some
>>>>>> home grown way of updating the DNS records. So we need to accommodate
>>>>>> this
>>>>>> use case (for example, making 'auto-registration' optional).
>>>>>>
>>>>>>
>>>>>> James.Strachan wrote:
>>>>>>>
>>>>>>> Ah cool thanks for that! I was wondering if an existing DNS library
>>>>>>> might be useful. e.g.
>>>>>>>
>>>>>>> http://www.dnsjava.org/
>>>>>>>
>>>>>>> which has a DNS client and server.
>>>>>>>
>>>>>>> I guess ZeroConf is kinda similar too; just not requiring a new or
>>>>>>> custom DNS server (though at the expense of requiring multicast
>>>>>>> support)
>>>>>>>
>>>>>>> 2008/5/19 Sridhar2008 <ac...@komandur.com>:
>>>>>>>>> Incidentally I'm intrigued by the DNS discovery stuff; it sounds
>>>>>>>>> >great
>>>>>>>>>:). What did you have in mind? That each broker on startup >would
>>>>>>>>>register a DNS entry (with a timeout maybe so they get >removed) and
>>>>>>>>
>>>>>>>> Yes, auto-registration.  Couple of things to note:
>>>>>>>>
>>>>>>>> - The 'timeout feature' again is DNS master specific, the existing
>>>>>>>> ones
>>>>>>>> need
>>>>>>>> to be enhanced to support this aging out. The standard timeout you
>>>>>>>> see
>>>>>>>> in
>>>>>>>> the DNS entry is for a different purpose: refresh between  master
>>>>>>>> and
>>>>>>>> slave
>>>>>>>> DNS servers.
>>>>>>>>
>>>>>>>> - There is no standard APY for web dns  registration, so we will
>>>>>>>> define
>>>>>>>> an
>>>>>>>> APY, with specific implementatioin to interact with the DNS server
>>>>>>>> (folks
>>>>>>>> can chose to change the implementation for their env).
>>>>>>>>
>>>>>>>> - Most messaging systems  run in trusted env, but some use cases may
>>>>>>>> need
>>>>>>>> authentication before a broker is allowed to do 'auto-registration'.
>>>>>>>> This
>>>>>>>> can be addressed later.
>>>>>>>>
>>>>>>>>>clients would ping DNS when attempting to connect in the
>>>>>>>>>FailoverTransport?
>>>>>>>>
>>>>>>>> Yes, we would specify the cluster name in client config and they
>>>>>>>> would
>>>>>>>> connect using 'ClusterTransport' :-)
>>>>>>>>
>>>>>>>>
>>>>>>>> James.Strachan wrote:
>>>>>>>>>
>>>>>>>>> 2008/5/15 Sridhar2008 <ac...@komandur.com>:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Rob/James,
>>>>>>>>>>
>>>>>>>>>> Thanks for the feedback. I will address both of your questions in
>>>>>>>>>> a
>>>>>>>>>> combined
>>>>>>>>>> way  :-)
>>>>>>>>>>
>>>>>>>>>> Rob> Do you need persistent messaging - or non-persistent only?
>>>>>>>>>> James> or just pick one broker per operation/transaction?
>>>>>>>>>>
>>>>>>>>>> Initially, it is going to be the above. Since the messaging usage
>>>>>>>>>> scenarios
>>>>>>>>>> are many, I will just assume the use case of interest for now is
>>>>>>>>>> durable
>>>>>>>>>> transfer using cluster for high availability.  In this case I am
>>>>>>>>>> not
>>>>>>>>>> sure
>>>>>>>>>> that it buys much to send to multiple brokers simultaneously (see
>>>>>>>>>> my
>>>>>>>>>> next
>>>>>>>>>> paragraph below) - adds additional headaches as James sites below
>>>>>>>>>> (however,
>>>>>>>>>> there may be other use cases where this might be useful), in
>>>>>>>>>> addition
>>>>>>>>>> to
>>>>>>>>>> making client-side logic complex.
>>>>>>>>>
>>>>>>>>> Agreed.
>>>>>>>>>
>>>>>>>>> For sending to a topic (outside of a transaction which may include
>>>>>>>>> other operations) then sending the message to all brokers is a no
>>>>>>>>> brainer. I guess so long as acknowledgements only get sent to the
>>>>>>>>> broker they came from & for queue sending we only send to one of
>>>>>>>>> the
>>>>>>>>> brokers it should be fairly straight forward.
>>>>>>>>>
>>>>>>>>> (So a little bit of hacking to the FanOutTransport should do the
>>>>>>>>> trick
>>>>>>>>> I
>>>>>>>>> think).
>>>>>>>>>
>>>>>>>>> We could get clever going forward; where rather than randomly
>>>>>>>>> picking
>>>>>>>>> one of the brokers (or round robbin) we kinda partition
>>>>>>>>> destinations
>>>>>>>>> across the available brokers?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Some thoughts: Eventual goal is a broker down in the cluster
>>>>>>>>>> implies
>>>>>>>>>> capacity hit and not a service hit. So, I will rather solve this
>>>>>>>>>> use
>>>>>>>>>> case
>>>>>>>>>> as
>>>>>>>>>> a distributed storage issue (after 'cluster transport' is added) -
>>>>>>>>>> investigate either a DHT based solution or perhaps something like
>>>>>>>>>> Hadoop
>>>>>>>>>> with a JDBC interface. The state is replicated in multiple nodes
>>>>>>>>>> of
>>>>>>>>>> the
>>>>>>>>>> cluster so the broker that is down can be ignored (ie no need to
>>>>>>>>>> sweat
>>>>>>>>>> on
>>>>>>>>>> recovering its state).
>>>>>>>>>
>>>>>>>>> Agreed.
>>>>>>>>>
>>>>>>>>> FWIW distributing the state is trivial - the FanOutTransport can do
>>>>>>>>> this today really. The issue is ensuring consistency (so more to do
>>>>>>>>> with locking & consistency than moving the messages around).
>>>>>>>>>
>>>>>>>>> Incidentally I'm intrigued by the DNS discovery stuff; it sounds
>>>>>>>>> great
>>>>>>>>> :). What did you have in mind? That each broker on startup would
>>>>>>>>> register a DNS entry (with a timeout maybe so they get removed) and
>>>>>>>>> clients would ping DNS when attempting to connect in the
>>>>>>>>> FailoverTransport?
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> James
>>>>>>>>> -------
>>>>>>>>> http://macstrac.blogspot.com/
>>>>>>>>>
>>>>>>>>> Open Source Integration
>>>>>>>>> http://open.iona.com
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> View this message in context:
>>>>>>>> http://www.nabble.com/Cluster-transport-...-tp17221068s2354p17323314.html
>>>>>>>> Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> James
>>>>>>> -------
>>>>>>> http://macstrac.blogspot.com/
>>>>>>>
>>>>>>> Open Source Integration
>>>>>>> http://open.iona.com
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> View this message in context:
>>>>>> http://www.nabble.com/Cluster-transport-...-tp17221068s2354p17323601.html
>>>>>> Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> James
>>>>> -------
>>>>> http://macstrac.blogspot.com/
>>>>>
>>>>> Open Source Integration
>>>>> http://open.iona.com
>>>>>
>>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>> http://www.nabble.com/Cluster-transport-...-tp17221068s2354p17323803.html
>>>> Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> James
>>> -------
>>> http://macstrac.blogspot.com/
>>>
>>> Open Source Integration
>>> http://open.iona.com
>>>
>>
>>
>>
>> --
>> Regards,
>> Hiram
>>
>> Blog: http://hiramchirino.com
>>
>> Open Source SOA
>> http://open.iona.com
>>
>>
>
> --
> View this message in context: http://www.nabble.com/Cluster-transport-...-tp17221068s2354p17416696.html
> Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
>
>



-- 
Regards,
Hiram

Blog: http://hiramchirino.com

Open Source SOA
http://open.iona.com

Re: Cluster transport ...

Posted by Sridhar2008 <ac...@komandur.com>.


James:

As you noted, the purge delay is not that big of a deal.

The case of  'cluster bootup' where there weren't any to begin with is a
legitimate use case. Again, how fast new  entries traverse from master to
slave DNS depends on implementation - for example, the refresh could be
quicker when there is a change.

Depending on how big a deal this use case is, there could be other options:
when a cluster name can't be resolved,  the discovery plugin can be
configured to go to a 'seed server' (which could be slower) and which
directly queries db or another possibility is for the 'name' to actually
resolve this 'seed server' cluster - which in essence is a distributed
membership service.

Hiram:

Perhaps you referring to nscd caching ?, otherwise I am not clear how a
client can influence slave-dns server behavior. We should probably defer any
non-standard tricks.

Thanks,
Regards,
- Sridhar Komandur


Hiram Chirino wrote:
> 
> On Tue, May 20, 2008 at 4:13 AM, James Strachan
> <ja...@gmail.com> wrote:
>> I'm not much of an expert in the behaviour of DNS servers :) so I
>> thought I'd think aloud a little...
>>
>> I guess we don't really care too much about old broker entries in DNS;
>> if a client can't connect it just tries the next one it finds - so its
>> really just an optimisation; a good DNS server would zap them quickly
>> but even if they stick around for 24 hours its not that big a deal as
>> there's hopefully not gonna be loads of brokers being started/stopped
>> on random IP addresses or anything :)
>>
>> The thing I'm pondering is if folks boot up a new broker on a new box,
>> we want clients to be able to find it pretty soon. In most DNS servers
>> you've worked with before - if you add a new entry (rather than
>> entries expiring) do servers tend to reflect that quickly to clients?
>> I can imagine in a highly federated DNS server network it might take a
>> while to propogate. Just wondered :)
>>
> 
> You could work around that with a smart client and DNS server.  Lets say
> that
> 
> cluster-a.mynetwork.com is hostname for the cluster.  If we want to
> avoid DNS caching of it's DNS records by my local DNS server, then the
> client could lookup ${timestamp}.cluster-a.mynetwork.com.  Basically
> change out the cache key.
> 
> Now, the DNS server admins might not like this usage pattern much so
> perhaps it's best to keep it optional.
> 
> 
>> 2008/5/19 Sridhar2008 <ac...@komandur.com>:
>>>
>>>>Agreed.
>>>>
>>>>We've got a pluggable discovery mechanism; both for the broker >to
>>>>advertise itself or for brokers/clients to discover things, so I >guess
>>>>DNS just becomes another provider.
>>>>http://activemq.apache.org/discovery.html
>>>
>>> Exactly ! The pluggable nature of ActiveMQ is great for enhancements
>>> like
>>> these.
>>>
>>>>The difference with DNS is you may use your existing DNS >provider or
>>>>might wanna run a custom implementation to get the timeout >stuff etc?
>>>
>>> Again, right on ! The timeout may not be that big a deal depending on
>>> the
>>> implementation ... for example, it might be a lazy cleanup process which
>>> may
>>> or may not be part of the DNS master server. For the clients (ie
>>> producers
>>> or consumers), if a broker in the list does not respond, it will just
>>> timeout to the next (note: 'next' could be as simple as next in the list
>>> or
>>> based on some policy).
>>>
>>>
>>> James.Strachan wrote:
>>>>
>>>> Agreed.
>>>>
>>>> We've got a pluggable discovery mechanism; both for the broker to
>>>> advertise itself or for brokers/clients to discover things, so I guess
>>>> DNS just becomes another provider.
>>>> http://activemq.apache.org/discovery.html
>>>>
>>>> The difference with DNS is you may use your existing DNS provider or
>>>> might wanna run a custom implementation to get the timeout stuff etc?
>>>>
>>>> 2008/5/19 Sridhar2008 <ac...@komandur.com>:
>>>>>
>>>>>
>>>>> Thanks for the link. I quickly glanced through the dnsjava website,
>>>>> and
>>>>> not
>>>>> clear if it requires a specific server for updates to work.
>>>>>
>>>>> Also, most large organizations have their own legacy DNS in place,
>>>>> with
>>>>> some
>>>>> home grown way of updating the DNS records. So we need to accommodate
>>>>> this
>>>>> use case (for example, making 'auto-registration' optional).
>>>>>
>>>>>
>>>>> James.Strachan wrote:
>>>>>>
>>>>>> Ah cool thanks for that! I was wondering if an existing DNS library
>>>>>> might be useful. e.g.
>>>>>>
>>>>>> http://www.dnsjava.org/
>>>>>>
>>>>>> which has a DNS client and server.
>>>>>>
>>>>>> I guess ZeroConf is kinda similar too; just not requiring a new or
>>>>>> custom DNS server (though at the expense of requiring multicast
>>>>>> support)
>>>>>>
>>>>>> 2008/5/19 Sridhar2008 <ac...@komandur.com>:
>>>>>>>> Incidentally I'm intrigued by the DNS discovery stuff; it sounds
>>>>>>>> >great
>>>>>>>>:). What did you have in mind? That each broker on startup >would
>>>>>>>>register a DNS entry (with a timeout maybe so they get >removed) and
>>>>>>>
>>>>>>> Yes, auto-registration.  Couple of things to note:
>>>>>>>
>>>>>>> - The 'timeout feature' again is DNS master specific, the existing
>>>>>>> ones
>>>>>>> need
>>>>>>> to be enhanced to support this aging out. The standard timeout you
>>>>>>> see
>>>>>>> in
>>>>>>> the DNS entry is for a different purpose: refresh between  master
>>>>>>> and
>>>>>>> slave
>>>>>>> DNS servers.
>>>>>>>
>>>>>>> - There is no standard APY for web dns  registration, so we will
>>>>>>> define
>>>>>>> an
>>>>>>> APY, with specific implementatioin to interact with the DNS server
>>>>>>> (folks
>>>>>>> can chose to change the implementation for their env).
>>>>>>>
>>>>>>> - Most messaging systems  run in trusted env, but some use cases may
>>>>>>> need
>>>>>>> authentication before a broker is allowed to do 'auto-registration'.
>>>>>>> This
>>>>>>> can be addressed later.
>>>>>>>
>>>>>>>>clients would ping DNS when attempting to connect in the
>>>>>>>>FailoverTransport?
>>>>>>>
>>>>>>> Yes, we would specify the cluster name in client config and they
>>>>>>> would
>>>>>>> connect using 'ClusterTransport' :-)
>>>>>>>
>>>>>>>
>>>>>>> James.Strachan wrote:
>>>>>>>>
>>>>>>>> 2008/5/15 Sridhar2008 <ac...@komandur.com>:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Rob/James,
>>>>>>>>>
>>>>>>>>> Thanks for the feedback. I will address both of your questions in
>>>>>>>>> a
>>>>>>>>> combined
>>>>>>>>> way  :-)
>>>>>>>>>
>>>>>>>>> Rob> Do you need persistent messaging - or non-persistent only?
>>>>>>>>> James> or just pick one broker per operation/transaction?
>>>>>>>>>
>>>>>>>>> Initially, it is going to be the above. Since the messaging usage
>>>>>>>>> scenarios
>>>>>>>>> are many, I will just assume the use case of interest for now is
>>>>>>>>> durable
>>>>>>>>> transfer using cluster for high availability.  In this case I am
>>>>>>>>> not
>>>>>>>>> sure
>>>>>>>>> that it buys much to send to multiple brokers simultaneously (see
>>>>>>>>> my
>>>>>>>>> next
>>>>>>>>> paragraph below) - adds additional headaches as James sites below
>>>>>>>>> (however,
>>>>>>>>> there may be other use cases where this might be useful), in
>>>>>>>>> addition
>>>>>>>>> to
>>>>>>>>> making client-side logic complex.
>>>>>>>>
>>>>>>>> Agreed.
>>>>>>>>
>>>>>>>> For sending to a topic (outside of a transaction which may include
>>>>>>>> other operations) then sending the message to all brokers is a no
>>>>>>>> brainer. I guess so long as acknowledgements only get sent to the
>>>>>>>> broker they came from & for queue sending we only send to one of
>>>>>>>> the
>>>>>>>> brokers it should be fairly straight forward.
>>>>>>>>
>>>>>>>> (So a little bit of hacking to the FanOutTransport should do the
>>>>>>>> trick
>>>>>>>> I
>>>>>>>> think).
>>>>>>>>
>>>>>>>> We could get clever going forward; where rather than randomly
>>>>>>>> picking
>>>>>>>> one of the brokers (or round robbin) we kinda partition
>>>>>>>> destinations
>>>>>>>> across the available brokers?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Some thoughts: Eventual goal is a broker down in the cluster
>>>>>>>>> implies
>>>>>>>>> capacity hit and not a service hit. So, I will rather solve this
>>>>>>>>> use
>>>>>>>>> case
>>>>>>>>> as
>>>>>>>>> a distributed storage issue (after 'cluster transport' is added) -
>>>>>>>>> investigate either a DHT based solution or perhaps something like
>>>>>>>>> Hadoop
>>>>>>>>> with a JDBC interface. The state is replicated in multiple nodes
>>>>>>>>> of
>>>>>>>>> the
>>>>>>>>> cluster so the broker that is down can be ignored (ie no need to
>>>>>>>>> sweat
>>>>>>>>> on
>>>>>>>>> recovering its state).
>>>>>>>>
>>>>>>>> Agreed.
>>>>>>>>
>>>>>>>> FWIW distributing the state is trivial - the FanOutTransport can do
>>>>>>>> this today really. The issue is ensuring consistency (so more to do
>>>>>>>> with locking & consistency than moving the messages around).
>>>>>>>>
>>>>>>>> Incidentally I'm intrigued by the DNS discovery stuff; it sounds
>>>>>>>> great
>>>>>>>> :). What did you have in mind? That each broker on startup would
>>>>>>>> register a DNS entry (with a timeout maybe so they get removed) and
>>>>>>>> clients would ping DNS when attempting to connect in the
>>>>>>>> FailoverTransport?
>>>>>>>>
>>>>>>>> --
>>>>>>>> James
>>>>>>>> -------
>>>>>>>> http://macstrac.blogspot.com/
>>>>>>>>
>>>>>>>> Open Source Integration
>>>>>>>> http://open.iona.com
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> View this message in context:
>>>>>>> http://www.nabble.com/Cluster-transport-...-tp17221068s2354p17323314.html
>>>>>>> Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> James
>>>>>> -------
>>>>>> http://macstrac.blogspot.com/
>>>>>>
>>>>>> Open Source Integration
>>>>>> http://open.iona.com
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> View this message in context:
>>>>> http://www.nabble.com/Cluster-transport-...-tp17221068s2354p17323601.html
>>>>> Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> James
>>>> -------
>>>> http://macstrac.blogspot.com/
>>>>
>>>> Open Source Integration
>>>> http://open.iona.com
>>>>
>>>>
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Cluster-transport-...-tp17221068s2354p17323803.html
>>> Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
>>>
>>>
>>
>>
>>
>> --
>> James
>> -------
>> http://macstrac.blogspot.com/
>>
>> Open Source Integration
>> http://open.iona.com
>>
> 
> 
> 
> -- 
> Regards,
> Hiram
> 
> Blog: http://hiramchirino.com
> 
> Open Source SOA
> http://open.iona.com
> 
> 

-- 
View this message in context: http://www.nabble.com/Cluster-transport-...-tp17221068s2354p17416696.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.