[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 updated JGRP-2474:
-------------------------------------
Attachment: log2.txt
> 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
> Attachments: JGR.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)
6 years
[JBoss JIRA] (JGRP-2304) ASYM_ENCRYPT: see if FragmentedMessages are handled correctly
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2304?page=com.atlassian.jira.plugin... ]
Bela Ban edited comment on JGRP-2304 at 5/7/20 7:43 AM:
--------------------------------------------------------
As suspected, this works with {{BytesMessage}} (which does _not_ use {{FragmentedMessage}}), but not with {{COMPRESS}} or {{ASYM_ENCRYPT}}.
See attached program and config (replace COMPRESS / ASM_ENCRYPT).
was (Author: belaban):
As suspected, this works with {{BytesMessage}} (which does _not_ use {{FragmentedMessage}}), but not with {{COMPRESS}} or {{ASYM_ENCRYPT}}
> ASYM_ENCRYPT: see if FragmentedMessages are handled correctly
> -------------------------------------------------------------
>
> Key: JGRP-2304
> URL: https://issues.redhat.com/browse/JGRP-2304
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 5.0.0.Beta1
>
> Attachments: asym-encrypt.xml, bla2.java
>
>
> Check the following scenario:
> * FRAG4 fragments a message into 4 FragmentedMessages
> * Confirm that ASYM_ENCRYPT correctly encrypts only the fragments
> Ditto for COMPRESS
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years