[
https://issues.jboss.org/browse/JGRP-2167?page=com.atlassian.jira.plugin....
]
Radim Vansa commented on JGRP-2167:
-----------------------------------
Then I suggest adding another counter (hs = highest sent?) that will keep this
information, and test this in {{LastSeqnoResender}}.
I suggest this as a workaround for now
I've already sent a PR with this workaround to Infinispan, but since you've closed
this as 'Won't fix', do you intend to ignore this issue completely? Have you
considered setting the default value for {{resend_last_seqno_max_times}} to a very high
value? A situation like this is non-trivial to detect & analyze, and user can end up
with blocked application for no obvious reason.
Highest seqno is not resent nor recorded on receivers
-----------------------------------------------------
Key: JGRP-2167
URL:
https://issues.jboss.org/browse/JGRP-2167
Project: JGroups
Issue Type: Bug
Affects Versions: 4.0.1
Reporter: Radim Vansa
Assignee: Bela Ban
Fix For: 4.0.2
I am investigating an issue in a stress test which leads me to a situation where in a
TCP-based configuration a {{GMS[VIEW]}} is broadcast to all nodes, but it is not received
by some of them. Soon after that there's a {{NAKACK2.HIGHEST_SEQNO}} that causes the
node that is missing the last seqno to resend it, but the retransmit is not received
either. There are no further retries, and generally no NAKACK2 activity until about 30
seconds later (when another node leaves after some timeout in the test).
The receiver does not keep asking for retransmissions until it gets them, but it seems
that {{NAKACK2.handleHighestSeqno}} doesn't update {{Table.hr}} (not sure if having
highest received set to non-received msg would be legal, though).
The sender uses default value {{NAKACK2.resend_last_seqno_max_times=1}}, and as there are
no further mcast messages, the highest sent seqno does not change on sender.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)