[
https://issues.jboss.org/browse/JGRP-1944?page=com.atlassian.jira.plugin....
]
Bram Klein Gunnewiek commented on JGRP-1944:
--------------------------------------------
I did some more testing and it seems to be related to the scripts {{ifup
<interface>}} and {{ifdown <interface>}} execute prior/post bringing the
actual interface up or down. Those commands execute the scripts in (on ubuntu)
{{/etc/network/if-\*}} where {{ifconfig <interface> down/up}} *only* brings the
interface down or up. Its related to the type of interface, if I reconfigure the network
cards to work as regular nic's jgroups auto recovers perfectly fine. So:
* {{ifdown bridge0}} and then {{ifup bridge0}} doesnt recover;
* {{ifconfig bridge0 down}} and then {{ifconfig bridge0 up}} does recover;
* {{ifdown eth0}} and then {{ifup eth0}} does recover (when the nic is configured as a
regular ethernet device ofcourse).
I'm still not sure if this is something JGroups should fix but its (at least in our
situations) common to bring interfaces down/up using ifdown / ifup. In case you'r
wondering: we use bridges instead of regular interfaces because they are also used by QEMU
instances.
jgroups does not recover properly when using UDP after ifdown / ifup
--------------------------------------------------------------------
Key: JGRP-1944
URL:
https://issues.jboss.org/browse/JGRP-1944
Project: JGroups
Issue Type: Bug
Affects Versions: 3.6.4
Environment: Linux Ubutun 14.04 where the network cards are configured as
bridges:
auto bridge0
iface bridge0 inet dhcp
bridge_ports eth1
bridge_stp off
bridge_fd 0
Reporter: Bram Klein Gunnewiek
Assignee: Bela Ban
Fix For: 3.6.5
Attachments: AutoRecoverMulticast.java
When we bring the interface down and back up in a complete (udp.xml) configuration
everything *seems* to be fine, however multicast traffic from the node that had the
interface brought down is not received by other nodes. The node also doesn't receive
any data from the other nodes. No exceptions are logged. I don't think the previous
test was done correctly by me ... sorry .
When we use TCP + MPING we see the stacktraces we had previously with UDP:
12:13:51.624 50644 [Timer-3,debug,shockvm-tn3-42192] ERROR unknown.jul.logger - failed
sending discovery request
java.io.IOException: Invalid argument
at java.net.PlainDatagramSocketImpl.send(Native Method) ~[na:1.7.0_79]
at java.net.DatagramSocket.send(DatagramSocket.java:697) ~[na:1.7.0_79]
at org.jgroups.protocols.MPING.sendMcastDiscoveryRequest(MPING.java:295)
~[jar:rsrc:jgroups-3.6.4.Final.jar!/:na]
at org.jgroups.protocols.PING.sendDiscoveryRequest(PING.java:61)
[jar:rsrc:jgroups-3.6.4.Final.jar!/:na]
at org.jgroups.protocols.PING.findMembers(PING.java:31)
[jar:rsrc:jgroups-3.6.4.Final.jar!/:na]
at org.jgroups.protocols.Discovery.findMembers(Discovery.java:244)
[jar:rsrc:jgroups-3.6.4.Final.jar!/:na]
at org.jgroups.protocols.Discovery.down(Discovery.java:387)
[jar:rsrc:jgroups-3.6.4.Final.jar!/:na]
at org.jgroups.protocols.MERGE3$InfoSender.run(MERGE3.java:382)
[jar:rsrc:jgroups-3.6.4.Final.jar!/:na]
at org.jgroups.util.TimeScheduler3$Task.run(TimeScheduler3.java:287)
[jar:rsrc:jgroups-3.6.4.Final.jar!/:na]
at org.jgroups.util.TimeScheduler3$RecurringTask.run(TimeScheduler3.java:321)
[jar:rsrc:jgroups-3.6.4.Final.jar!/:na]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
[na:1.7.0_79]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
[na:1.7.0_79]
at java.lang.Thread.run(Thread.java:745) [na:1.7.0_79]
(The exact message differs whether or not the -Djava.net.preferIPv4Stack=true argument is
configured)
A configuration that uses MPING also doesn't recover from ifdown/ifup.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)