[JBoss JIRA] (WFLY-3046) Not possible change the object store type from hornetq to jdbc via cli commands
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3046?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3046:
-----------------------------------------------
Ivo Studensky <istudens(a)redhat.com> changed the Status of [bug 1038993|https://bugzilla.redhat.com/show_bug.cgi?id=1038993] from ASSIGNED to POST
> Not possible change the object store type from hornetq to jdbc via cli commands
> -------------------------------------------------------------------------------
>
> Key: WFLY-3046
> URL: https://issues.jboss.org/browse/WFLY-3046
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Transactions
> Affects Versions: 8.0.0.Final
> Reporter: Ivo Studensky
> Assignee: Ivo Studensky
> Fix For: 8.0.1.Final
>
>
> When you have set the object store to be type of hornetq and then you change your mind to set it for jdbc object store the jboss-cli permits this operation but no change is propagated to model and XML file.
> How to reproduce:
> # ./bin/standalone.xml (start eap 6.2.0.GA)
> # ./bin/jboss-cli.sh -c (connect to running eap)
> # /subsystem=transactions:write-attribute(name=use-hornetq-store, value=true)
> # :reload# /subsystem=transactions/log-store=log-store:read-attribute(name=type)# /subsystem=transactions:write-attribute(name=use-jdbc-store, value=true)# :reload
> # /subsystem=transactions/log-store=log-store:read-attribute(name=type)
> The object store stays to be set to hornetq and no change happens in the standalone.xml file.
--
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
12 years, 1 month
[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 closed WFLY-3003.
--------------------------------
Resolution: Duplicate Issue
Duplicates WFLY-2632.
> 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
12 years, 1 month
[JBoss JIRA] (JGRP-1814) No physical address for X; dropping message
by Bela Ban (JIRA)
Bela Ban created JGRP-1814:
------------------------------
Summary: No physical address for X; dropping message
Key: JGRP-1814
URL: https://issues.jboss.org/browse/JGRP-1814
Project: JGroups
Issue Type: Enhancement
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 3.5
When we have view \{A,B\} and B leaves, then the following happens in UNICAST3:
* B sends a LEAVE-REQ to A
* A sends a LEAVE-RSP to B
* Because the LEAVE-RSP is reliable, A keeps sending the LEAVE-RSP to B until it receives an ACK for the LEAVE-RSP
* However, when B receives the LEAVE-RSP, it marks its connection to be acked, which means that when the next retransmission kicks in, an ACK for the LEAVE-RSP will be sent back to A
* Before this happens, B leaves: the ACK is never sent to A
* A keeps resending the LEAVE-RSP until {{max_retransmit_time}} (default=60s) elapses and the connection is closed. However, the connection is only closed after another 60s (default for {{conn_close_timeout}}).
* Because the reaper removes all entries of {{logical_addr_cache}} before that happens, we're seeing the above warnings
SOLUTION:
# Send LEAVE-RSP unreliable. This bypasses UNICAST3 altogether. The leaver won't block forever if the LEAVE-RSP message is dropped, but only for 3 x {{GMS.leave_timeout}} ms
# Also add a MBR_LEFT event which is sent up and down the stack by GMS when a member left *gracefully*. This allows UNICAST3 to close the connection to a given member *immediately*, stopping unneeded retransmissions to members which left.
--
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
12 years, 1 month
[JBoss JIRA] (WFLY-3046) Not possible change the object store type from hornetq to jdbc via cli commands
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3046?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3046:
-----------------------------------------------
Ivo Studensky <istudens(a)redhat.com> changed the Status of [bug 1038993|https://bugzilla.redhat.com/show_bug.cgi?id=1038993] from NEW to ASSIGNED
> Not possible change the object store type from hornetq to jdbc via cli commands
> -------------------------------------------------------------------------------
>
> Key: WFLY-3046
> URL: https://issues.jboss.org/browse/WFLY-3046
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Transactions
> Affects Versions: 8.0.0.Final
> Reporter: Ivo Studensky
> Assignee: Ivo Studensky
> Fix For: 8.0.1.Final
>
>
> When you have set the object store to be type of hornetq and then you change your mind to set it for jdbc object store the jboss-cli permits this operation but no change is propagated to model and XML file.
> How to reproduce:
> # ./bin/standalone.xml (start eap 6.2.0.GA)
> # ./bin/jboss-cli.sh -c (connect to running eap)
> # /subsystem=transactions:write-attribute(name=use-hornetq-store, value=true)
> # :reload# /subsystem=transactions/log-store=log-store:read-attribute(name=type)# /subsystem=transactions:write-attribute(name=use-jdbc-store, value=true)# :reload
> # /subsystem=transactions/log-store=log-store:read-attribute(name=type)
> The object store stays to be set to hornetq and no change happens in the standalone.xml file.
--
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
12 years, 1 month
[JBoss JIRA] (WFLY-3003) Dropping unicast message to wrong destination warn after cluster node rejoin
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-3003?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz commented on WFLY-3003:
-------------------------------------------
Sorry for the late reply, got bogged down with other stuff.
This is a known issue: https://issues.jboss.org/browse/WFLY-2632
Bela has responded here: https://issues.jboss.org/browse/JGRP-1755
> 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
12 years, 1 month
[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
12 years, 1 month
[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
12 years, 1 month
[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
12 years, 1 month