[JBoss JIRA] (DROOLS-871) Remove the MVEL dependency from kie-internal
by Marco Rietveld (JIRA)
[ https://issues.jboss.org/browse/DROOLS-871?page=com.atlassian.jira.plugin... ]
Marco Rietveld commented on DROOLS-871:
---------------------------------------
[~mfusco] I've assigned this to you, but feel free to assign it to Edson or Mark if you want to -- or back to me. :)
> Remove the MVEL dependency from kie-internal
> --------------------------------------------
>
> Key: DROOLS-871
> URL: https://issues.jboss.org/browse/DROOLS-871
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Reporter: Marco Rietveld
> Assignee: Mario Fusco
> Fix For: 6.2.0.Final, 6.3.0.Final
>
>
> The {{kie-internal}} module has a dependency on MVEL. This jira is for the task of removing that dependency from {{kie-internal}}.
> The problem is that the MVEL dependency ({{org.mvel:mvel2}}) is nearly 1MB large!
> This means that the dependency tree grows by 1MB everywhere where {{kie-internal}} is used, among others: {{kie-remote-client}}, which has the explicit goal of being as small a dependency as possible, given that it's meant to be used as a lightweight client jar.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (DROOLS-871) Remove the MVEL dependency from kie-internal
by Marco Rietveld (JIRA)
Marco Rietveld created DROOLS-871:
-------------------------------------
Summary: Remove the MVEL dependency from kie-internal
Key: DROOLS-871
URL: https://issues.jboss.org/browse/DROOLS-871
Project: Drools
Issue Type: Bug
Components: core engine
Reporter: Marco Rietveld
Assignee: Mario Fusco
Fix For: 6.3.0.Final, 6.2.0.Final
The {{kie-internal}} module has a dependency on MVEL. This jira is for the task of removing that dependency from {{kie-internal}}.
The problem is that the MVEL dependency ({{org.mvel:mvel2}}) is nearly 1MB large!
This means that the dependency tree grows by 1MB everywhere where {{kie-internal}} is used, among others: {{kie-remote-client}}, which has the explicit goal of being as small a dependency as possible, given that it's meant to be used as a lightweight client jar.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (JGRP-1944) jgroups does not recover properly when using UDP after ifdown / ifup
by Bram Klein Gunnewiek (JIRA)
[ https://issues.jboss.org/browse/JGRP-1944?page=com.atlassian.jira.plugin.... ]
Bram Klein Gunnewiek commented on JGRP-1944:
--------------------------------------------
I will try to figure out what part of the ifup / ifdown scripts cause this behavior on bridge devices. We could fix the problem in the scripts, problem is other parties using our software on regular Linux installations might run into the same problem. Only thing we can currently do is give them a big fat warning that our software needs to be restarted when something like this has been done.
I understand its a difficult one to fix in JGroups especially if you have to rely on a pretty generic IOException. Maybe I can think of a way to detect these problems in a custom protocol or something and pass it up so I can restart the JGroups cluster in our application.
In https://issues.jboss.org/browse/JGRP-1804 changes where made to the UDP protocol that now mask the problems that occur after ifdown / ifup (it had the same kind of Exceptions as the MPING protocol). I think the changes made because of that issue should be reverted since complete silence is even worse?
> 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)
10 years, 11 months
[JBoss JIRA] (JGRP-1944) jgroups does not recover properly when using UDP after ifdown / ifup
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1944?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1944:
--------------------------------
There may never be a send() by a member, if a member only listens for messages but never sends. I can also not rely on JGroups sending multicasts, as FD_ALL may be absent and STABLE sends unicasts (to the coordd) only...
The other issue is that catching an IOException is pretty broad exception to catch, to re-register mcast routes.
> 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)
10 years, 11 months
[JBoss JIRA] (JGRP-1944) jgroups does not recover properly when using UDP after ifdown / ifup
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1944?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1944:
--------------------------------
Can't you look into why {{ifconfig down bridge0}} doesn't remove the IGMP registrations, whereas {{ifdown bridge0}} does ? If you can change the scripts associated with {{ifdown}} to *not* remove the IGMP registrations, then things would work.
> 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)
10 years, 11 months
[JBoss JIRA] (JGRP-1944) jgroups does not recover properly when using UDP after ifdown / ifup
by Bram Klein Gunnewiek (JIRA)
[ https://issues.jboss.org/browse/JGRP-1944?page=com.atlassian.jira.plugin.... ]
Bram Klein Gunnewiek commented on JGRP-1944:
--------------------------------------------
Are there cases where only {{ MulticastSocket.receive() }} is used and no packets are send? E.G. in the MPING protocol its (I think?) guaranteed that {{MulticastSocket.send()}} is used on a set interval. Isn't it the same with the UDP transfer protocol?
I've read through the link you added to this issue and there doesn't seem to be a clean solution afaik. I'm still not sure why this is only breaking when the nic's are configured as bridges.
> 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)
10 years, 11 months
[JBoss JIRA] (JGRP-1944) jgroups does not recover properly when using UDP after ifdown / ifup
by Bram Klein Gunnewiek (JIRA)
[ https://issues.jboss.org/browse/JGRP-1944?page=com.atlassian.jira.plugin.... ]
Bram Klein Gunnewiek edited comment on JGRP-1944 at 8/4/15 4:30 AM:
--------------------------------------------------------------------
Are there cases where only {{MulticastSocket.receive()}} is used and no packets are send? E.G. in the MPING protocol its (I think?) guaranteed that {{MulticastSocket.send()}} is used on a set interval. Isn't it the same with the UDP transfer protocol?
I've read through the link you added to this issue and there doesn't seem to be a clean solution afaik. I'm still not sure why this is only breaking when the nic's are configured as bridges.
was (Author: bramklg):
Are there cases where only {{ MulticastSocket.receive() }} is used and no packets are send? E.G. in the MPING protocol its (I think?) guaranteed that {{MulticastSocket.send()}} is used on a set interval. Isn't it the same with the UDP transfer protocol?
I've read through the link you added to this issue and there doesn't seem to be a clean solution afaik. I'm still not sure why this is only breaking when the nic's are configured as bridges.
> 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)
10 years, 11 months
[JBoss JIRA] (JGRP-1944) jgroups does not recover properly when using UDP after ifdown / ifup
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1944?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1944:
--------------------------------
I don't see how this could be done at the JGroups level.
On the sender side, we could recreate the sender socket on an "Invalid argument" IOException, but that would not fix the receiver: the {{MulticastSocket.receive()}} call does *not* return or throw an exception on an ifdown, so there is no way to get notified when this happens, to re-register the multicast groups.
> 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)
10 years, 11 months
[JBoss JIRA] (JGRP-1944) jgroups does not recover properly when using UDP after ifdown / ifup
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1944?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1944 at 8/4/15 4:10 AM:
--------------------------------------------------------
The reason for IP multicast loss is that the application doesn't re-register its multicast groups after an ifdown-ifup cycle.
If you run {{netstat -ng}} before ifdown-ifup and after, the routes to {{224.0.75.75}} (probe) and {{228.8.8.8}} (UDP) are lost.
I need to investigate whether this can be done by JGroups...
was (Author: belaban):
The reason for IP multicast loss is that the application doesn't re-register its multicast groups after an ifdown-ipup cycle.
If you run {{netstat -ng}} before ifdown-ifup and after, the routes to {{224.0.75.75}} (probe) and {{228.8.8.8}} (UDP) are lost.
I need to investigate whether this can be done by JGroups...
> 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)
10 years, 11 months
[JBoss JIRA] (WFCORE-865) Patching regression between WFCore 2.0.0.Alpha9 and Alpha11
by Ladislav Thon (JIRA)
[ https://issues.jboss.org/browse/WFCORE-865?page=com.atlassian.jira.plugin... ]
Ladislav Thon updated WFCORE-865:
---------------------------------
Attachment: test-patch-10.0.0.Alpha5.zip
test-patch-10.0.0.Alpha6.zip
> Patching regression between WFCore 2.0.0.Alpha9 and Alpha11
> -----------------------------------------------------------
>
> Key: WFCORE-865
> URL: https://issues.jboss.org/browse/WFCORE-865
> Project: WildFly Core
> Issue Type: Bug
> Components: Patching
> Affects Versions: 2.0.0.Alpha11
> Reporter: Ladislav Thon
> Assignee: Alexey Loubyansky
> Attachments: test-patch-10.0.0.Alpha5.zip, test-patch-10.0.0.Alpha6.zip
>
>
> With WildFly 10.0.0.Alpha5 (Core 2.0.0.Alpha9):
> {code}
> ./wildfly-10.0.0.Alpha5/bin/jboss-cli.sh --command="patch apply test-patch-10.0.0.Alpha5.zip"
> {
> "outcome" : "success",
> "result" : {}
> }
> ./wildfly-10.0.0.Alpha5/bin/jboss-cli.sh --command="patch history"
> {
> "outcome" : "success",
> "result" : [{
> "patch-id" : "test-patch",
> "type" : "cumulative",
> "applied-at" : "8/4/15 9:07 AM"
> }]
> }
> ./wildfly-10.0.0.Alpha5/bin/jboss-cli.sh --command="patch info"
> Version: undefined
> Cumulative patch ID: test-patch
> One-off patches: none
> {code}
> With WildFly 10.0.0.Alpha6 (Core 2.0.0.Alpha11):
> {code}
> ./wildfly-10.0.0.Alpha6/bin/jboss-cli.sh --command="patch apply test-patch-10.0.0.Alpha6.zip"
> {
> "outcome" : "success",
> "result" : {}
> }
> ./wildfly-10.0.0.Alpha6/bin/jboss-cli.sh --command="patch history"
> {
> "outcome" : "success",
> "result" : []
> }
> ./wildfly-10.0.0.Alpha6/bin/jboss-cli.sh --command="patch info"
> Version: undefined
> Cumulative patch ID: base
> One-off patches: none
> {code}
> With WildFly 10.0.0.Alpha6, based on {{patch history}} and {{patch info}}, it looks like the patch doesn't even apply, but that's not actually true, because trying to apply the patch once again results in
> {code}
> WFLYPAT0039: Requested WildFly version 10.0.0.Alpha6 did not match the installed version 10.0.0.Alpha6_PATCHED
> {code}
> So the patch in fact _is_ installed, it's just that neither {{patch history}} nor {{patch info}} doesn't show it like it used to.
> The only reason I could come up with is that I use {{EAP}} as the {{<upgrade name="...">}}:
> {code}
> <upgrade name="EAP" version="10.0.0.Alpha6" to-version="10.0.0.Alpha6_PATCHED"/>
> {code}
> However:
> 1. This used to work just fine in WildFly 10.0.0.Alpha5 and before.
> 2. If this is now considered wrong, the patch shouldn't even apply in the first place.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months