[JBoss JIRA] (JGRP-1801) DuplicateTest fails when testing OOB multicast to all three senders
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/JGRP-1801?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz edited comment on JGRP-1801 at 3/26/14 10:20 AM:
---------------------------------------------------------------------
Even if I adjust the timeout to wait for 60 seconds, I still get failures.
I added in code to print a dot (.) after each second of waiting. In passing tests, I see this:
{noformat}
------------- testOOBMulticastToAll3Senders -----------
Checking for messages from all senders:
.
[C1]: C1: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
[C1]: C2: [9, 2, 1, 10, 3, 5, 6, 7, 4, 8]
[C1]: c3: [1, 10, 2, 3, 5, 4, 8, 9, 7, 6]
Checking for messages from all senders:
[C2]: C1: [1, 2, 10, 3, 4, 6, 8, 9, 5, 7]
[C2]: C2: [3, 1, 2, 4, 5, 6, 7, 8, 9, 10]
[C2]: c3: [2, 5, 6, 1, 10, 3, 7, 8, 9, 4]
Checking for messages from all senders:
[C3]: C1: [1, 2, 10, 3, 4, 5, 6, 7, 8, 9]
[C3]: C2: [1, 10, 2, 3, 4, 5, 6, 7, 8, 9]
[C3]: c3: [1, 8, 2, 3, 4, 5, 9, 10, 7, 6]
{noformat}
but in the faiiing tests, I see this:
{noformat}
------------- testOOBMulticastToAll3Senders -----------
Checking for messages from all senders:
[C1]: C1: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
[C1]: C2: [1, 6, 5, 2, 3, 4, 10, 7, 8, 9]
[C1]: c3: [1, 10, 2, 3, 4, 6, 7, 8, 9, 5]
Checking for messages from all senders:
[C2]: C1: [1, 2, 3, 10, 4, 5, 7, 8, 9, 6]
[C2]: C2: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
[C2]: c3: [1, 5, 2, 3, 4, 10, 6, 7, 8, 9]
Checking for messages from all senders:
............................................................
{noformat}
In other words, even with a timeout of 60 seconds, on channel C3, messages are not being received from one of the three channels. It seems that something (either sending or receiving) is getting "stuck".
Again, disabling the OOB thread pool fixes things.
was (Author: rachmato):
Even if I adjust the timeout to wait for 60 seconds, I still get failures.
I added in code to print a dot (.) after each second of waiting. In passing tests, I see this:
{noformat}
------------- testOOBMulticastToAll3Senders -----------
Checking for messages from all senders:
.
[C1]: C1: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
[C1]: C2: [9, 2, 1, 10, 3, 5, 6, 7, 4, 8]
[C1]: c3: [1, 10, 2, 3, 5, 4, 8, 9, 7, 6]
Checking for messages from all senders:
[C2]: C1: [1, 2, 10, 3, 4, 6, 8, 9, 5, 7]
[C2]: C2: [3, 1, 2, 4, 5, 6, 7, 8, 9, 10]
[C2]: c3: [2, 5, 6, 1, 10, 3, 7, 8, 9, 4]
Checking for messages from all senders:
[C3]: C1: [1, 2, 10, 3, 4, 5, 6, 7, 8, 9]
[C3]: C2: [1, 10, 2, 3, 4, 5, 6, 7, 8, 9]
[C3]: c3: [1, 8, 2, 3, 4, 5, 9, 10, 7, 6]
{noformat}
but in the faiiing tests, I see this:
{noformat}
------------- testOOBMulticastToAll3Senders -----------
Checking for messages from all senders:
[C1]: C1: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
[C1]: C2: [1, 6, 5, 2, 3, 4, 10, 7, 8, 9]
[C1]: c3: [1, 10, 2, 3, 4, 6, 7, 8, 9, 5]
Checking for messages from all senders:
[C2]: C1: [1, 2, 3, 10, 4, 5, 7, 8, 9, 6]
[C2]: C2: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
[C2]: c3: [1, 5, 2, 3, 4, 10, 6, 7, 8, 9]
Checking for messages from all senders:
............................................................
{noformat}
In other words, even with a timeout of 60 seconds, on channel C3, messages are not being received from one of the three channels. It seems that something (either sending or receiving) is getting "stuck".
> DuplicateTest fails when testing OOB multicast to all three senders
> -------------------------------------------------------------------
>
> Key: JGRP-1801
> URL: https://issues.jboss.org/browse/JGRP-1801
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.13
> Environment: Windows (18), Solaris (2), RHEL(1) where (x) is the number of failures seen
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Fix For: 3.2.14
>
>
> DuplicateTest does the following:
> - creates three channels containing the DUPL layer called c1, c2, c3
> - DUPL is used to duplicate messages sent
> - channel receiver for channel each keeps a map of messages received from each sender
> - channels send messages: regular, OOB, or mixed
> - the test checks that the messages received by each channel are correct in number and in order
> The test testOOBMuloticastToAll3Senders is failing regularly on multple platforms. The test makes each of the channels send OOB multicast messages to the group, but only two of three members ever end up receiving the multicast messages. Al example of the failure:
> {noformat}
> Error Message
> expected size=3, msgs: [C2, C1]
> Stacktrace
> java.lang.AssertionError
> at org.jgroups.tests.DuplicateTest.check(DuplicateTest.java:217)
> at org.jgroups.tests.DuplicateTest.testOOBMulticastToAll3Senders(DuplicateTest.java:123)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 9 months
[JBoss JIRA] (JGRP-1801) DuplicateTest fails when testing OOB multicast to all three senders
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/JGRP-1801?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz commented on JGRP-1801:
-------------------------------------------
Even if I adjust the timeout to wait for 60 seconds, I still get failures.
I added in code to print a dot (.) after each second of waiting. In passing tests, I see this:
{noformat}
------------- testOOBMulticastToAll3Senders -----------
Checking for messages from all senders:
.
[C1]: C1: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
[C1]: C2: [9, 2, 1, 10, 3, 5, 6, 7, 4, 8]
[C1]: c3: [1, 10, 2, 3, 5, 4, 8, 9, 7, 6]
Checking for messages from all senders:
[C2]: C1: [1, 2, 10, 3, 4, 6, 8, 9, 5, 7]
[C2]: C2: [3, 1, 2, 4, 5, 6, 7, 8, 9, 10]
[C2]: c3: [2, 5, 6, 1, 10, 3, 7, 8, 9, 4]
Checking for messages from all senders:
[C3]: C1: [1, 2, 10, 3, 4, 5, 6, 7, 8, 9]
[C3]: C2: [1, 10, 2, 3, 4, 5, 6, 7, 8, 9]
[C3]: c3: [1, 8, 2, 3, 4, 5, 9, 10, 7, 6]
{noformat}
but in the faiiing tests, I see this:
{nofomat}
------------- testOOBMulticastToAll3Senders -----------
Checking for messages from all senders:
[C1]: C1: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
[C1]: C2: [1, 6, 5, 2, 3, 4, 10, 7, 8, 9]
[C1]: c3: [1, 10, 2, 3, 4, 6, 7, 8, 9, 5]
Checking for messages from all senders:
[C2]: C1: [1, 2, 3, 10, 4, 5, 7, 8, 9, 6]
[C2]: C2: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
[C2]: c3: [1, 5, 2, 3, 4, 10, 6, 7, 8, 9]
Checking for messages from all senders:
............................................................
{noformat}
In other words, even with a timeout of 60 seconds, on channel C3, messages are not being received from one of the three channels.
> DuplicateTest fails when testing OOB multicast to all three senders
> -------------------------------------------------------------------
>
> Key: JGRP-1801
> URL: https://issues.jboss.org/browse/JGRP-1801
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.13
> Environment: Windows (18), Solaris (2), RHEL(1) where (x) is the number of failures seen
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Fix For: 3.2.14
>
>
> DuplicateTest does the following:
> - creates three channels containing the DUPL layer called c1, c2, c3
> - DUPL is used to duplicate messages sent
> - channel receiver for channel each keeps a map of messages received from each sender
> - channels send messages: regular, OOB, or mixed
> - the test checks that the messages received by each channel are correct in number and in order
> The test testOOBMuloticastToAll3Senders is failing regularly on multple platforms. The test makes each of the channels send OOB multicast messages to the group, but only two of three members ever end up receiving the multicast messages. Al example of the failure:
> {noformat}
> Error Message
> expected size=3, msgs: [C2, C1]
> Stacktrace
> java.lang.AssertionError
> at org.jgroups.tests.DuplicateTest.check(DuplicateTest.java:217)
> at org.jgroups.tests.DuplicateTest.testOOBMulticastToAll3Senders(DuplicateTest.java:123)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 9 months
[JBoss JIRA] (JGRP-1801) DuplicateTest fails when testing OOB multicast to all three senders
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/JGRP-1801?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz edited comment on JGRP-1801 at 3/26/14 10:08 AM:
---------------------------------------------------------------------
Even if I adjust the timeout to wait for 60 seconds, I still get failures.
I added in code to print a dot (.) after each second of waiting. In passing tests, I see this:
{noformat}
------------- testOOBMulticastToAll3Senders -----------
Checking for messages from all senders:
.
[C1]: C1: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
[C1]: C2: [9, 2, 1, 10, 3, 5, 6, 7, 4, 8]
[C1]: c3: [1, 10, 2, 3, 5, 4, 8, 9, 7, 6]
Checking for messages from all senders:
[C2]: C1: [1, 2, 10, 3, 4, 6, 8, 9, 5, 7]
[C2]: C2: [3, 1, 2, 4, 5, 6, 7, 8, 9, 10]
[C2]: c3: [2, 5, 6, 1, 10, 3, 7, 8, 9, 4]
Checking for messages from all senders:
[C3]: C1: [1, 2, 10, 3, 4, 5, 6, 7, 8, 9]
[C3]: C2: [1, 10, 2, 3, 4, 5, 6, 7, 8, 9]
[C3]: c3: [1, 8, 2, 3, 4, 5, 9, 10, 7, 6]
{noformat}
but in the faiiing tests, I see this:
{noformat}
------------- testOOBMulticastToAll3Senders -----------
Checking for messages from all senders:
[C1]: C1: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
[C1]: C2: [1, 6, 5, 2, 3, 4, 10, 7, 8, 9]
[C1]: c3: [1, 10, 2, 3, 4, 6, 7, 8, 9, 5]
Checking for messages from all senders:
[C2]: C1: [1, 2, 3, 10, 4, 5, 7, 8, 9, 6]
[C2]: C2: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
[C2]: c3: [1, 5, 2, 3, 4, 10, 6, 7, 8, 9]
Checking for messages from all senders:
............................................................
{noformat}
In other words, even with a timeout of 60 seconds, on channel C3, messages are not being received from one of the three channels. It seems that something (either sending or receiving) is getting "stuck".
was (Author: rachmato):
Even if I adjust the timeout to wait for 60 seconds, I still get failures.
I added in code to print a dot (.) after each second of waiting. In passing tests, I see this:
{noformat}
------------- testOOBMulticastToAll3Senders -----------
Checking for messages from all senders:
.
[C1]: C1: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
[C1]: C2: [9, 2, 1, 10, 3, 5, 6, 7, 4, 8]
[C1]: c3: [1, 10, 2, 3, 5, 4, 8, 9, 7, 6]
Checking for messages from all senders:
[C2]: C1: [1, 2, 10, 3, 4, 6, 8, 9, 5, 7]
[C2]: C2: [3, 1, 2, 4, 5, 6, 7, 8, 9, 10]
[C2]: c3: [2, 5, 6, 1, 10, 3, 7, 8, 9, 4]
Checking for messages from all senders:
[C3]: C1: [1, 2, 10, 3, 4, 5, 6, 7, 8, 9]
[C3]: C2: [1, 10, 2, 3, 4, 5, 6, 7, 8, 9]
[C3]: c3: [1, 8, 2, 3, 4, 5, 9, 10, 7, 6]
{noformat}
but in the faiiing tests, I see this:
{nofomat}
------------- testOOBMulticastToAll3Senders -----------
Checking for messages from all senders:
[C1]: C1: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
[C1]: C2: [1, 6, 5, 2, 3, 4, 10, 7, 8, 9]
[C1]: c3: [1, 10, 2, 3, 4, 6, 7, 8, 9, 5]
Checking for messages from all senders:
[C2]: C1: [1, 2, 3, 10, 4, 5, 7, 8, 9, 6]
[C2]: C2: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
[C2]: c3: [1, 5, 2, 3, 4, 10, 6, 7, 8, 9]
Checking for messages from all senders:
............................................................
{noformat}
In other words, even with a timeout of 60 seconds, on channel C3, messages are not being received from one of the three channels.
> DuplicateTest fails when testing OOB multicast to all three senders
> -------------------------------------------------------------------
>
> Key: JGRP-1801
> URL: https://issues.jboss.org/browse/JGRP-1801
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.13
> Environment: Windows (18), Solaris (2), RHEL(1) where (x) is the number of failures seen
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Fix For: 3.2.14
>
>
> DuplicateTest does the following:
> - creates three channels containing the DUPL layer called c1, c2, c3
> - DUPL is used to duplicate messages sent
> - channel receiver for channel each keeps a map of messages received from each sender
> - channels send messages: regular, OOB, or mixed
> - the test checks that the messages received by each channel are correct in number and in order
> The test testOOBMuloticastToAll3Senders is failing regularly on multple platforms. The test makes each of the channels send OOB multicast messages to the group, but only two of three members ever end up receiving the multicast messages. Al example of the failure:
> {noformat}
> Error Message
> expected size=3, msgs: [C2, C1]
> Stacktrace
> java.lang.AssertionError
> at org.jgroups.tests.DuplicateTest.check(DuplicateTest.java:217)
> at org.jgroups.tests.DuplicateTest.testOOBMulticastToAll3Senders(DuplicateTest.java:123)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 9 months
[JBoss JIRA] (WFLY-3003) Dropping unicast message to wrong destination warn after cluster node rejoin
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3003?page=com.atlassian.jira.plugin.... ]
Radoslav Husar edited comment on WFLY-3003 at 3/26/14 9:55 AM:
---------------------------------------------------------------
I am seeing this quite often, here is some basic information to should narrow this down very much:
* Happens just after restarting one of the cluster nodes.
* Error is gone when the entire cluster is restarted instead.
* The logging is happening on the node being restarted.
* Cleaning up /data, /tmp, /log does not help.
* Every restart adds one more line of logging.
* After some timeout, when the node is rejoining, the warnings are gone.
14:51:13,596 WARN [org.jgroups.protocols.UDP] (Timer-4,shared=udp) JGRP000032: null: no physical address for x220/ejb, dropping message
14:51:13,630 WARN [org.jgroups.protocols.UNICAST3] (OOB-20,shared=udp) JGRP000040: rhusar2/web: sender x220/web not found in retransmission table
was (Author: rhusar):
I am seeing this quite often, just after restarting one of the cluster nodes. Seems to log until entire cluster is restarted.
> Dropping unicast message to wrong destination warn after cluster node rejoin
> ----------------------------------------------------------------------------
>
> Key: WFLY-3003
> URL: https://issues.jboss.org/browse/WFLY-3003
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Clustering
> Affects Versions: 8.0.0.Final
> Reporter: Eduardo Martins
> Assignee: Richard Achmatowicz
> Priority: Critical
> Fix For: 8.0.1.Final
>
>
> There is a never ending warn log message printed after a cluster node rejoins, after a shutdown:
> 03:43:15,831 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:15,831 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:15,887 INFO [org.jboss.as.server] (Controller Boot Thread) JBAS018559: Deployed "wildfly-cluster-ha-singleton-service.jar" (runtime-name : "wildfly-cluster-ha-singleton-service.jar")
> 03:43:15,895 INFO [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://127.0.0.1:10090/management
> 03:43:15,895 INFO [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://127.0.0.1:10090
> 03:43:15,896 INFO [org.jboss.as] (Controller Boot Thread) JBAS015874: WildFly 8.0.1.Final-SNAPSHOT "WildFly" started in 4855ms - Started 345 of 437 services (171 services are lazy, passive or on-demand)
> 03:43:16,332 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:16,332 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:16,833 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:16,834 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:17,335 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:17,336 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:17,835 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:17,836 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:18,335 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:18,336 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:18,837 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:18,838 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:19,339 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:19,340 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:19,840 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:19,840 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:20,003 INFO [org.jboss.as.quickstarts.cluster.hasingleton.service.ejb.SchedulerBean] (EJB default - 1) HASingletonTimer: Info=HASingleton timer @nodeTwo Sat Feb 22 03:43:15 WET 2014
> 03:43:20,003 INFO [org.jboss.as.quickstarts.cluster.hasingleton.service.ejb.SchedulerBean] (EJB default - 2) HASingletonTimer: Info=HASingleton timer @nodeTwo Sat Feb 22 03:43:15 WET 2014
> 03:43:20,341 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:20,342 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:20,841 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:20,842 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:21,342 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:21,342 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:21,842 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:21,843 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:22,343 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:22,344 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:22,845 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:22,845 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:23,345 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:23,346 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:23,846 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:23,846 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> This can be seen using WildFly's cluster-ha-singleton quickstart (github project wildfly/quickstart). Just follow quickstart’s readme till point 4 of "Check the timer" section, and after stop node2 (not node1) start it gain.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 9 months
[JBoss JIRA] (WFLY-3003) Dropping unicast message to wrong destination warn after cluster node rejoin
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3003?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-3003:
---------------------------------
Fix Version/s: 8.0.1.Final
Priority: Critical (was: Major)
Affects Version/s: 8.0.0.Final
I am seeing this quite often, just after restarting one of the cluster nodes. Seems to log until entire cluster is restarted.
> Dropping unicast message to wrong destination warn after cluster node rejoin
> ----------------------------------------------------------------------------
>
> Key: WFLY-3003
> URL: https://issues.jboss.org/browse/WFLY-3003
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Clustering
> Affects Versions: 8.0.0.Final
> Reporter: Eduardo Martins
> Assignee: Richard Achmatowicz
> Priority: Critical
> Fix For: 8.0.1.Final
>
>
> There is a never ending warn log message printed after a cluster node rejoins, after a shutdown:
> 03:43:15,831 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:15,831 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:15,887 INFO [org.jboss.as.server] (Controller Boot Thread) JBAS018559: Deployed "wildfly-cluster-ha-singleton-service.jar" (runtime-name : "wildfly-cluster-ha-singleton-service.jar")
> 03:43:15,895 INFO [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://127.0.0.1:10090/management
> 03:43:15,895 INFO [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://127.0.0.1:10090
> 03:43:15,896 INFO [org.jboss.as] (Controller Boot Thread) JBAS015874: WildFly 8.0.1.Final-SNAPSHOT "WildFly" started in 4855ms - Started 345 of 437 services (171 services are lazy, passive or on-demand)
> 03:43:16,332 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:16,332 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:16,833 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:16,834 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:17,335 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:17,336 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:17,835 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:17,836 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:18,335 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:18,336 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:18,837 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:18,838 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:19,339 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:19,340 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:19,840 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:19,840 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:20,003 INFO [org.jboss.as.quickstarts.cluster.hasingleton.service.ejb.SchedulerBean] (EJB default - 1) HASingletonTimer: Info=HASingleton timer @nodeTwo Sat Feb 22 03:43:15 WET 2014
> 03:43:20,003 INFO [org.jboss.as.quickstarts.cluster.hasingleton.service.ejb.SchedulerBean] (EJB default - 2) HASingletonTimer: Info=HASingleton timer @nodeTwo Sat Feb 22 03:43:15 WET 2014
> 03:43:20,341 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:20,342 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:20,841 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:20,842 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:21,342 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:21,342 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:21,842 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:21,843 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:22,343 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:22,344 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:22,845 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:22,845 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:23,345 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:23,346 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> 03:43:23,846 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
> 03:43:23,846 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
> This can be seen using WildFly's cluster-ha-singleton quickstart (github project wildfly/quickstart). Just follow quickstart’s readme till point 4 of "Check the timer" section, and after stop node2 (not node1) start it gain.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 9 months
[JBoss JIRA] (WFLY-3171) Increase default state transfer timeout
by Paul Ferraro (JIRA)
Paul Ferraro created WFLY-3171:
----------------------------------
Summary: Increase default state transfer timeout
Key: WFLY-3171
URL: https://issues.jboss.org/browse/WFLY-3171
Project: WildFly
Issue Type: Enhancement
Security Level: Public (Everyone can see)
Components: Clustering
Affects Versions: 8.0.0.Final
Reporter: Paul Ferraro
Assignee: Paul Ferraro
The current state transfer timeout is 1 minute. Now that Infinispan uses non-blocking state transfer, we should bump this to 4 minutes, in line with Infinispan's defaults.
Don't forget to include transformers for old model versions.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 9 months
[JBoss JIRA] (WFLY-3170) system properties are trim()'d and loose whitespace
by Tom Fonteyne (JIRA)
[ https://issues.jboss.org/browse/WFLY-3170?page=com.atlassian.jira.plugin.... ]
Tom Fonteyne commented on WFLY-3170:
------------------------------------
it would be for STRING as it looks.
But I agree that while the change is trivial, it would have system-wide (potential) repercussions.
> system properties are trim()'d and loose whitespace
> ---------------------------------------------------
>
> Key: WFLY-3170
> URL: https://issues.jboss.org/browse/WFLY-3170
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 8.0.1.Final
> Reporter: Tom Fonteyne
> Assignee: Brian Stansberry
>
> When a system property was defined as:
> /system-property=foo:add(value=" spaces ");
> it gets written with the correct spaces around it to the configuration file.
> When the configuration is read the value gets trimmed and the prefix/suffix of spaces is lost.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 9 months
[JBoss JIRA] (WFLY-3164) Create customized Audit Logger
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-3164?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-3164:
----------------------------------------
Can I assign this to you? I think you have a better grasp of the topic. :)
This sounds like a good approach. I expect we are going to have to create static variant of this that does some basic mappings of a few fields to traditional log record elements, but as you say having the SPI etc needed for this custom formatter approach will make doing that static one simpler; it will just be a less configurable thing that calls into the same logic.
> Create customized Audit Logger
> ------------------------------
>
> Key: WFLY-3164
> URL: https://issues.jboss.org/browse/WFLY-3164
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Reporter: Kabir Khan
> Assignee: Brian Stansberry
> Labels: EAP
> Fix For: 9.0.0.CR1
>
>
> Some users want to have a single line audit log formatter. I think it would be better to have the ability to add your own formatter from a module, something along the lines of:
> {code}
> <custom-formatter code="org.blah.MyCustomFormatter" module="org.blah/mymodule">
> <property name="layout">...</property>
> <property name="propB">...</property>
> </custom-formatter>
> {code}
> We'd need an SPI, and a slight reworking of the audit log internals. In any case doing this will put us in a better position to provide the single line logger if this proposal is not acceptable to our users.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 9 months