August 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-2474) Messages about dropped queued message when using IpAddressUUID

by Mirko Streckenbach (Jira)

[ https://issues.redhat.com/browse/JGRP-2474?page=com.atlassian.jira.plugin... ] Mirko Streckenbach commented on JGRP-2474: ------------------------------------------ [~belaban] Yes, you can close this. > Messages about dropped queued message when using IpAddressUUID > -------------------------------------------------------------- > > Key: JGRP-2474 > URL: https://issues.redhat.com/browse/JGRP-2474 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.2.3 > Reporter: Mirko Streckenbach > Assignee: Bela Ban > Priority: Major > Fix For: 4.2.5 > > Attachments: JGR.java, JGR.java, JGR2.java, log-fail-1.txt, log2.txt > > > We upgraded from 4.0.14 to 4.1.8 and ever since then, we had some messages like > {code} > Apr 27, 2020 10:30:54 AM org.jgroups.protocols.UNICAST3 addQueuedMessages > WARNING: i2:1709: dropped queued message i1:1609#2 as its conn_id (0) did not match (entry.conn_id=1) > {code} > when ever an application is restarted. Our setup is as follows (most due to network restrictions): > * Fixed port numbers > * JDBC_PING > * We use IpAddressUUID in order to have a "readable" information in the jgroupsping table > I could track this down to 4.1.2 / 4.1.3: 4.1.2 works as expected, from 4.1.3 I'm seeing the effect observed above. > I attached a simple example that demonstrates the problem: starts two stacks, shuts down the second (non-coordindator) and starts it again after a couple of seconds. With 4.1.2 this works as expected (no warnings), but 4.1.3 and more recent versions (including 4.2.3) produce warnings. The exact behavior is not completely consistent: in most cases, starting the second app again results in some timeouts and the second app becomes a coordinator itself and a merge view is established later (log attached). In some cases it only creates the warnings shown above (this is what we observe in our real application) and in some cases everything works fine. > I don't have any warnings in the log if I don't set an AddressGenerator, but I'd like to avoid this. > While running this on higher debug levels, I observed the following: 4.1.2 will not require an > ACK for the LEAVE_RSP message. 4.1.3 will. The second app sends the ACK, but the coordinator does not seem to receive or process it properly and retransmits the LEAVE_RSP message again and again. This is independent of the AddressGenerator used, -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2474) Messages about dropped queued message when using IpAddressUUID

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2474?page=com.atlassian.jira.plugin... ] Bela Ban commented on JGRP-2474: -------------------------------- Pinning an application to a single port is not an issue: if the port is not available, the app won't start and JGroups will throw an exception. With UUIDs, you won't run into reincarnation issues. Can I close this issue then? Cheers, > Messages about dropped queued message when using IpAddressUUID > -------------------------------------------------------------- > > Key: JGRP-2474 > URL: https://issues.redhat.com/browse/JGRP-2474 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.2.3 > Reporter: Mirko Streckenbach > Assignee: Bela Ban > Priority: Major > Fix For: 4.2.5 > > Attachments: JGR.java, JGR.java, JGR2.java, log-fail-1.txt, log2.txt > > > We upgraded from 4.0.14 to 4.1.8 and ever since then, we had some messages like > {code} > Apr 27, 2020 10:30:54 AM org.jgroups.protocols.UNICAST3 addQueuedMessages > WARNING: i2:1709: dropped queued message i1:1609#2 as its conn_id (0) did not match (entry.conn_id=1) > {code} > when ever an application is restarted. Our setup is as follows (most due to network restrictions): > * Fixed port numbers > * JDBC_PING > * We use IpAddressUUID in order to have a "readable" information in the jgroupsping table > I could track this down to 4.1.2 / 4.1.3: 4.1.2 works as expected, from 4.1.3 I'm seeing the effect observed above. > I attached a simple example that demonstrates the problem: starts two stacks, shuts down the second (non-coordindator) and starts it again after a couple of seconds. With 4.1.2 this works as expected (no warnings), but 4.1.3 and more recent versions (including 4.2.3) produce warnings. The exact behavior is not completely consistent: in most cases, starting the second app again results in some timeouts and the second app becomes a coordinator itself and a merge view is established later (log attached). In some cases it only creates the warnings shown above (this is what we observe in our real application) and in some cases everything works fine. > I don't have any warnings in the log if I don't set an AddressGenerator, but I'd like to avoid this. > While running this on higher debug levels, I observed the following: 4.1.2 will not require an > ACK for the LEAVE_RSP message. 4.1.3 will. The second app sends the ACK, but the coordinator does not seem to receive or process it properly and retransmits the LEAVE_RSP message again and again. This is independent of the AddressGenerator used, -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2474) Messages about dropped queued message when using IpAddressUUID

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2474?page=com.atlassian.jira.plugin... ] Bela Ban edited comment on JGRP-2474 at 8/10/20 2:11 PM: --------------------------------------------------------- [~belaban]Thanks for coming back to this and providing the information. We switch from {{IpAddressUUID}} to UUID based from your first comment (and the fact that it will be gone in a future release) so this solved the immediate issue. Unfortunately our target environment does not give us the liberty of choosing random ports and so we are limited to use a fixed ip/port for one application. We hat reincarnation issues before we switched from {{IpAddress}} to {{IpAddressUUID}}, but never hat any problems with reincarnation after the switch. Fortunately, the missing close was only the example and not in the real code. Again, many thanks. was (Author: pms1): [~belaban]Thanks for coming back to this and providing the information. We switch from {{IpAddressUUID}} to UUID based from your first comment (and the fact that it will be gone in a future release) so this solved the immediate issue. Unfortunately our target environment does not give us the liberty of choosing random ports and so we are limited to use a fixed ip/port for one application. We hat reincarnation issues before we switched from {{IpAddress }} to {{IpAddressUUID}}, but never hat any problems with reincarnation after the switch. Fortunately, the missing close was only the example and not in the real code. Again, many thanks. > Messages about dropped queued message when using IpAddressUUID > -------------------------------------------------------------- > > Key: JGRP-2474 > URL: https://issues.redhat.com/browse/JGRP-2474 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.2.3 > Reporter: Mirko Streckenbach > Assignee: Bela Ban > Priority: Major > Fix For: 4.2.5 > > Attachments: JGR.java, JGR.java, JGR2.java, log-fail-1.txt, log2.txt > > > We upgraded from 4.0.14 to 4.1.8 and ever since then, we had some messages like > {code} > Apr 27, 2020 10:30:54 AM org.jgroups.protocols.UNICAST3 addQueuedMessages > WARNING: i2:1709: dropped queued message i1:1609#2 as its conn_id (0) did not match (entry.conn_id=1) > {code} > when ever an application is restarted. Our setup is as follows (most due to network restrictions): > * Fixed port numbers > * JDBC_PING > * We use IpAddressUUID in order to have a "readable" information in the jgroupsping table > I could track this down to 4.1.2 / 4.1.3: 4.1.2 works as expected, from 4.1.3 I'm seeing the effect observed above. > I attached a simple example that demonstrates the problem: starts two stacks, shuts down the second (non-coordindator) and starts it again after a couple of seconds. With 4.1.2 this works as expected (no warnings), but 4.1.3 and more recent versions (including 4.2.3) produce warnings. The exact behavior is not completely consistent: in most cases, starting the second app again results in some timeouts and the second app becomes a coordinator itself and a merge view is established later (log attached). In some cases it only creates the warnings shown above (this is what we observe in our real application) and in some cases everything works fine. > I don't have any warnings in the log if I don't set an AddressGenerator, but I'd like to avoid this. > While running this on higher debug levels, I observed the following: 4.1.2 will not require an > ACK for the LEAVE_RSP message. 4.1.3 will. The second app sends the ACK, but the coordinator does not seem to receive or process it properly and retransmits the LEAVE_RSP message again and again. This is independent of the AddressGenerator used, -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2474) Messages about dropped queued message when using IpAddressUUID

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2474?page=com.atlassian.jira.plugin... ] Bela Ban edited comment on JGRP-2474 at 8/10/20 2:06 PM: --------------------------------------------------------- [~belaban]Thanks for coming back to this and providing the information. We switch from {{IpAddressUUID}} to UUID based from your first comment (and the fact that it will be gone in a future release) so this solved the immediate issue. Unfortunately our target environment does not give us the liberty of choosing random ports and so we are limited to use a fixed ip/port for one application. We hat reincarnation issues before we switched from {{IpAddress }} to {{IpAddressUUID}}, but never hat any problems with reincarnation after the switch. Fortunately, the missing close was only the example and not in the real code. Again, many thanks. was (Author: pms1): [~belaban]Thanks for coming back to this and providing the information. We switch from {{IpAddressUUID}} to UUID based from your first comment (and the fact that it will be gone in a future release) so this solved the immediate issue. Unfortunately our target environment does not give us the liberty of choosing random ports and so we are limited to use a fixed ip/port for one application. We hat reincarnation issues before we switched from {{IpAddress }}to {{IpAddressUUID, }}but never hat any problems with reincarnation after the switch. Fortunately, the missing close was only the example and not in the real code. Again, many thanks. > Messages about dropped queued message when using IpAddressUUID > -------------------------------------------------------------- > > Key: JGRP-2474 > URL: https://issues.redhat.com/browse/JGRP-2474 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.2.3 > Reporter: Mirko Streckenbach > Assignee: Bela Ban > Priority: Major > Fix For: 4.2.5 > > Attachments: JGR.java, JGR.java, JGR2.java, log-fail-1.txt, log2.txt > > > We upgraded from 4.0.14 to 4.1.8 and ever since then, we had some messages like > {code} > Apr 27, 2020 10:30:54 AM org.jgroups.protocols.UNICAST3 addQueuedMessages > WARNING: i2:1709: dropped queued message i1:1609#2 as its conn_id (0) did not match (entry.conn_id=1) > {code} > when ever an application is restarted. Our setup is as follows (most due to network restrictions): > * Fixed port numbers > * JDBC_PING > * We use IpAddressUUID in order to have a "readable" information in the jgroupsping table > I could track this down to 4.1.2 / 4.1.3: 4.1.2 works as expected, from 4.1.3 I'm seeing the effect observed above. > I attached a simple example that demonstrates the problem: starts two stacks, shuts down the second (non-coordindator) and starts it again after a couple of seconds. With 4.1.2 this works as expected (no warnings), but 4.1.3 and more recent versions (including 4.2.3) produce warnings. The exact behavior is not completely consistent: in most cases, starting the second app again results in some timeouts and the second app becomes a coordinator itself and a merge view is established later (log attached). In some cases it only creates the warnings shown above (this is what we observe in our real application) and in some cases everything works fine. > I don't have any warnings in the log if I don't set an AddressGenerator, but I'd like to avoid this. > While running this on higher debug levels, I observed the following: 4.1.2 will not require an > ACK for the LEAVE_RSP message. 4.1.3 will. The second app sends the ACK, but the coordinator does not seem to receive or process it properly and retransmits the LEAVE_RSP message again and again. This is independent of the AddressGenerator used, -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13760) Upgrade smallrye-fault-tolerance to 4.3.0

by Radoslav Husar (Jira)

[ https://issues.redhat.com/browse/WFLY-13760?page=com.atlassian.jira.plugi... ] Radoslav Husar updated WFLY-13760: ---------------------------------- Description: Changes: [https://github.com/smallrye/smallrye-fault-tolerance/compare/4.2.1...4.3....] was: Changes: https://github.com/smallrye/smallrye-fault-tolerance/compare/4.2.0...4.2.1 > Upgrade smallrye-fault-tolerance to 4.3.0 > ----------------------------------------- > > Key: WFLY-13760 > URL: https://issues.redhat.com/browse/WFLY-13760 > Project: WildFly > Issue Type: Component Upgrade > Components: MP Fault Tolerance > Affects Versions: 20.0.0.Final, 20.0.1.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Major > Fix For: 21.0.0.Beta1 > > > Changes: > [https://github.com/smallrye/smallrye-fault-tolerance/compare/4.2.1...4.3....] -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13760) Upgrade smallrye-fault-tolerance to 4.3.0

by Radoslav Husar (Jira)

[ https://issues.redhat.com/browse/WFLY-13760?page=com.atlassian.jira.plugi... ] Radoslav Husar updated WFLY-13760: ---------------------------------- Description: Changes: https://github.com/smallrye/smallrye-fault-tolerance/compare/4.2.1...4.3.0 was: Changes: [https://github.com/smallrye/smallrye-fault-tolerance/compare/4.2.1...4.3....] > Upgrade smallrye-fault-tolerance to 4.3.0 > ----------------------------------------- > > Key: WFLY-13760 > URL: https://issues.redhat.com/browse/WFLY-13760 > Project: WildFly > Issue Type: Component Upgrade > Components: MP Fault Tolerance > Affects Versions: 20.0.0.Final, 20.0.1.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Major > Fix For: 21.0.0.Beta1 > > > Changes: > https://github.com/smallrye/smallrye-fault-tolerance/compare/4.2.1...4.3.0 -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13760) Upgrade smallrye-fault-tolerance to 4.3.0

by Radoslav Husar (Jira)

[ https://issues.redhat.com/browse/WFLY-13760?page=com.atlassian.jira.plugi... ] Radoslav Husar updated WFLY-13760: ---------------------------------- Git Pull Request: (was: https://github.com/wildfly/wildfly/pull/13333) > Upgrade smallrye-fault-tolerance to 4.3.0 > ----------------------------------------- > > Key: WFLY-13760 > URL: https://issues.redhat.com/browse/WFLY-13760 > Project: WildFly > Issue Type: Component Upgrade > Components: MP Fault Tolerance > Affects Versions: 20.0.0.Beta1 > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Major > Fix For: 20.0.0.Final > > > Changes: > https://github.com/smallrye/smallrye-fault-tolerance/compare/4.2.0...4.2.1 -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13760) Upgrade smallrye-fault-tolerance to 4.3.0

by Radoslav Husar (Jira)

[ https://issues.redhat.com/browse/WFLY-13760?page=com.atlassian.jira.plugi... ] Radoslav Husar updated WFLY-13760: ---------------------------------- Fix Version/s: (was: 20.0.0.Final) > Upgrade smallrye-fault-tolerance to 4.3.0 > ----------------------------------------- > > Key: WFLY-13760 > URL: https://issues.redhat.com/browse/WFLY-13760 > Project: WildFly > Issue Type: Component Upgrade > Components: MP Fault Tolerance > Affects Versions: 20.0.0.Beta1 > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Major > > Changes: > https://github.com/smallrye/smallrye-fault-tolerance/compare/4.2.0...4.2.1 -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13760) Upgrade smallrye-fault-tolerance to 4.3.0

by Radoslav Husar (Jira)

[ https://issues.redhat.com/browse/WFLY-13760?page=com.atlassian.jira.plugi... ] Radoslav Husar updated WFLY-13760: ---------------------------------- Affects Version/s: 20.0.1.Final 20.0.0.Final (was: 20.0.0.Beta1) > Upgrade smallrye-fault-tolerance to 4.3.0 > ----------------------------------------- > > Key: WFLY-13760 > URL: https://issues.redhat.com/browse/WFLY-13760 > Project: WildFly > Issue Type: Component Upgrade > Components: MP Fault Tolerance > Affects Versions: 20.0.0.Final, 20.0.1.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Major > > Changes: > https://github.com/smallrye/smallrye-fault-tolerance/compare/4.2.0...4.2.1 -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13760) Upgrade smallrye-fault-tolerance to 4.3.0

by Radoslav Husar (Jira)

[ https://issues.redhat.com/browse/WFLY-13760?page=com.atlassian.jira.plugi... ] Radoslav Husar updated WFLY-13760: ---------------------------------- Fix Version/s: 21.0.0.Beta1 > Upgrade smallrye-fault-tolerance to 4.3.0 > ----------------------------------------- > > Key: WFLY-13760 > URL: https://issues.redhat.com/browse/WFLY-13760 > Project: WildFly > Issue Type: Component Upgrade > Components: MP Fault Tolerance > Affects Versions: 20.0.0.Final, 20.0.1.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Major > Fix For: 21.0.0.Beta1 > > > Changes: > https://github.com/smallrye/smallrye-fault-tolerance/compare/4.2.0...4.2.1 -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2020