cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter Schuller (JIRA)" <>
Subject [jira] Commented: (CASSANDRA-628) Invalid argument / Network is unreachable
Date Fri, 22 Oct 2010 07:18:16 GMT


Peter Schuller commented on CASSANDRA-628:

I agree. FWIW, this is an issue on FreeBSD too, so it's not limited to Linux (I'm not sure
whether there is an equivalent to the sysctl work-around).

Googling for this issue I know lots of people seem to be running into this and asking about
it on forums etc (not specifically to Cassandra). In the case of Cassandra, for many people
it may be their first use of a production Java app. Assuming a non-programmer user, failing
on this issue by default and having to figure out or ask about a stack trace is not a very
good first-time experience.

While ideologically one might go for the "it's the user's responsibility to sort out his networking"
argument, until IPv6 is more widely used it really seems like a completely sensible default.
The level of expected clue expected if you're running in an IPv6 environment is currently
high enough that having to nudge this system property is not an issue (especially if there's
a faq entry/note about its use somewhere).

> Invalid argument / Network
is unreachable
> ----------------------------------------------------------------------------------------------------
>                 Key: CASSANDRA-628
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>         Environment: Linux, FreeBSD, (possibly others)
>            Reporter: Eric Evans
>            Assignee: Eric Evans
> This manifests as either a SocketException that occurs when starting a cassandra node,
or a NoRouteToHostException which occurs when connecting with a client.
> On Linux systems this is caused by IPV6_V6ONLY being set true. The docs (ipv6(7)) say
that when set this causes sockets to be created IPv6 only, while the previous behavior also
allowed sending and receiving packets using an  IPv4-mapped IPv6 address.
> The quick fix is to either launch applications using the
property, or on Linux systems set net.ipv6.bindv6only=0 (see sysctl(8)).
> My limited understanding is that the previous behavior (IPV6_V6ONLY=0) was always considered
a hack to be used until IPv6 was more mature/had gained traction and that a change in defaults
was always inevitable, so in the long-term a Real Fix will be needed.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message