[
https://jira.jboss.org/jira/browse/JGRP-1156?page=com.atlassian.jira.plug...
]
Bela Ban closed JGRP-1156.
--------------------------
Resolution: Rejected
I'm not going to fix this for the following reasons:
- Disabling and re-enabling the NIC is not a very valid use case IMO
- This only happens on Windows
- Workaround is to create a logical NIC, similar to IP Bonding on Linux
- Switch to a TCP based config, as TCP sockets are not affected
- If I handled NoRouteToHostExceptions, and re-created the multicast and datagram sockets,
this could also happen when the routing table is misconfigured, so we'd constantly
recreate sockets. IMO, it is not worth adding such dangerous code, which handles an edge
case that almost never occurs in real life
Recreate socket on NoRouteToHost exception
------------------------------------------
Key: JGRP-1156
URL:
https://jira.jboss.org/jira/browse/JGRP-1156
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 2.10
I've got a customer [1] that started receiving the following error during multicast
sends (from MERGE in this particular log) until JBoss was restarted:
[Email Dennis]
[org.jgroups.protocols.UDP] [ERROR] failed sending message to null (0 bytes)
java.net.NoRouteToHostException: No route to host: Datagram send failed
I've had one other case with this symptom. In that case, they had bonded network
interfaces and were testing failover by bringing one side of it down.
It looks to me like something is screwed up at the OS level that doesn't get fixed
until JBoss is restarted (or the socket is recreated?).
Is there anything we could do about this at the JGroups level? The customer has asked
why we don't recreate the socket when this exception happens. But that doesn't
seem like a good solution to me since there's nothing about a NoRouteToHostException
that should indicate the socket needs recreated.
-Dennis
[End email Dennis]
One thing we could investigate is to close and recreate a socket when such an exception
is encountered. Possibly other exceptions as well...
This would affect the transports (UDP and TCP), plus some of the protocols which use
sockets, e.g. MPING, FD_SOCK, STREAMING_STATE_TRANSFER etc...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira