incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Dusbabek <>
Subject Re: finding Cassandra servers
Date Wed, 03 Mar 2010 16:25:27 GMT
-1 core.
+1 contrib.
+10 github.

Client-endpoint discovery is not currently addressed at all in the
codebase.  I don't think it is a job we should take up because needs
will vary across applications and there isn't a general solution that
will work for everybody.


2010/3/3 Ted Zlatanov <>:
> On Wed, 3 Mar 2010 09:32:33 -0600 Gary Dusbabek <> wrote:
> GD> 2010/3/3 Ted Zlatanov <>:
>>> This requires knowledge of the seeds so I need to at least look in
>>> storage-conf.xml to find them.  Are you saying there's no chance of
>>> Cassandra nodes (or just seeds) announcing themselves, even if it's
>>> optional behavior that's off by default?  If so I'll do the contrib mDNS
>>> service but it really seems like a backward way to do things.
> GD> Nodes already announce themselves, only just to the cluster.  That's
> GD> what gossip is for.  I don't see the point of making the announcement
> GD> to the subnet at large.
> GD> The decision rests with the community.  Obviously, if there is enough
> GD> merit to this work, it will find its way into the codebase.  I just
> GD> think it falls into the realm of shiny-and-neat (mdns and automatic
> GD> discovery is cool) and not in the realm of pragmatic (not reliable
> GD> across subnets).
> It's currently not possible to find a usable node without running
> centralized services like RRDNS or a special mDNS broadcaster as you
> suggested.  I don't think this is shiny and neat, it's a matter of
> running in a true decentralized environment (which Cassandra is supposed
> to fit into).
> The subnet limitation is not an issue in my environment (we forward
> much, much larger multicast volumes routinely) but I understand routing
> multicasts is not everyone's cup of tea.  IMHO it's better than the
> current situation and, mDNS being a well-known standard, can at least be
> handled at the switch level without code changes.
> I can do a patch+ticket for this in the core, making it optional and off
> by default, or do the same for a contrib/ service as you suggested.  So
> I'd appreciate a +1/-1 quick vote on whether this can go in the core to
> save me from rewriting the patch later.
> Ted

View raw message