[
https://issues.apache.org/jira/browse/CASSANDRA-14361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16425647#comment-16425647
]
Ben Bromhead edited comment on CASSANDRA-14361 at 4/4/18 2:52 PM:
------------------------------------------------------------------
{quote}JVM property {{networkaddress.cache.ttl}} must be set otherwise
operators will have to do a rolling restart of the cluster each time the seed
list changes (unless default is not {{-1}} on their platforms).
{quote}
Caching behavior remains the same, given operators relying on hostnames in the
seed list would need to be aware of this anyway, whether it looks up one IP or
multiple. Also the JVM will only cache forever by default if a security manager
is installed. If a security manager is not installed each specific JVM
implementations can have a potentially different TTL, but a defined TTL
nonetheless. See
[https://docs.oracle.com/javase/8/docs/technotes/guides/net/properties.html].
{quote}This would also affect the third gossip round:
[https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/gms/Gossiper.java#L185]
{quote}
Ah, of course.
If you are already using hostnames in the seed list, the behavior would still
be the same? Other than your list of seeds potentially containing seed IPs you
might not expect, if you are returning multiple IPs per A record, but not
relying on the behavior. Resulting in potentially more gossip rounds to hit the
IP you used to expect?
I've marked this as a 4.0 patch, so I think a change in behavior would be fine.
I've created another ticket
https://issues.apache.org/jira/browse/CASSANDRA-14364 to document seed behavior
with relation to the third gossip round and DNS (including caching) behavior.
was (Author: benbromhead):
{quote}
JVM property {{{{networkaddress.cache.ttl}}}} must be set otherwise operators
will have to do a rolling restart of the cluster each time the seed list
changes (unless default is not {{{{-1}}}} on their platforms).
{quote}
Caching behavior remains the same, given operators relying on hostnames in the
seed list would need to be aware of this anyway, whether it looks up one IP or
multiple. Also the JVM will only cache forever by default if a security manager
is installed. If a security manager is not installed each specific JVM
implementations can have a potentially different TTL, but a defined TTL
nonetheless. See
[https://docs.oracle.com/javase/8/docs/technotes/guides/net/properties.html].
{quote}
This would also affect the third gossip round:
[https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/gms/Gossiper.java#L185]
{quote}
Ah, of course.
If you are already using hostnames in the seed list, the behavior would still
be the same? Other than your list of seeds potentially containing seed IPs you
might not expect, if you are returning multiple IPs per A record, but not
relying on the behavior. Resulting in potentially more gossip rounds to hit the
IP you used to expect?
I've marked this as a 4.0 patch, so I think a change in behavior would be fine.
I've created another ticket
https://issues.apache.org/jira/browse/CASSANDRA-14364 to document seed behavior
with relation to the third gossip round and DNS (including caching) behavior.
> Allow SimpleSeedProvider to resolve multiple IPs per DNS name
> -------------------------------------------------------------
>
> Key: CASSANDRA-14361
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14361
> Project: Cassandra
> Issue Type: Improvement
> Components: Configuration
> Reporter: Ben Bromhead
> Assignee: Ben Bromhead
> Priority: Minor
> Fix For: 4.0
>
>
> Currently SimpleSeedProvider can accept a comma separated string of IPs or
> hostnames as the set of Cassandra seeds. hostnames are resolved via
> InetAddress.getByName, which will only return the first IP associated with an
> A, AAAA or CNAME record.
> By changing to InetAddress.getAllByName, existing behavior is preserved, but
> now Cassandra can discover multiple IP address per record, allowing seed
> discovery by DNS to be a little easier.
> Some examples of improved workflows with this change include:
> * specify the DNS name of a headless service in Kubernetes which will
> resolve to all IP addresses of pods within that service.
> * seed discovery for multi-region clusters via AWS route53, AzureDNS etc
> * Other common DNS service discovery mechanisms.
> The only behavior this is likely to impact would be where users are relying
> on the fact that getByName only returns a single IP address.
> I can't imagine any scenario where that is a sane choice. Even when that
> choice has been made, it only impacts the first startup of Cassandra and
> would not be on any critical path.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
