activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hiram Chirino" <hi...@hiramchirino.com>
Subject Re: Cluster transport ...
Date Tue, 27 May 2008 13:20:22 GMT
On Thu, May 22, 2008 at 8:58 PM, Sridhar2008 <activemq@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
>> <james.strachan@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 <activemq@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 <activemq@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 <activemq@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 <activemq@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

Mime
View raw message