[ 
https://issues.apache.org/jira/browse/CASSANDRA-628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12923789#action_12923789
 ] 

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).


> java.net.SocketException: Invalid argument / java.net.NoRouteToHostException: 
> Network is unreachable
> ----------------------------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-628
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-628
>             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 
> -Djava.net.preferIPv4Stack=true 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.
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6342561
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=560056

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

Reply via email to