[jboss-jira] [JBoss JIRA] (JGRP-1963) TCP_NIO2 starts dropping messages
[
https://issues.jboss.org/browse/JGRP-1963?page=com.atlassian.jira.plugin....
]
Bela Ban commented on JGRP-1963:
--------------------------------
Ok, so here's what happens:
* Apparently an {{OP_CONNECT}} flag on an already connected channel leads to a loop with
{{select()}} always returning 0
* So {{OP_CONNECT}} has to be cleared. However...
* While {{OP_CONNECT}} is cleared in the select-loop, {{OP_READ}} is added by reading the
old value of interestOps (still {{OP_CONNECT}} !) and anding it with {{OP_READ}} -->
{{OP_CONNECT | OP_READ}}
* This is because {{SelectionKey.interestOps(ops)}} is not thread safe.
SOLUTION: write a method to change the selection key which is thread safe and has to be
used by all threads
TCP_NIO2 starts dropping messages
---------------------------------
Key: JGRP-1963
URL: https://issues.jboss.org/browse/JGRP-1963
Project: JGroups
Issue Type: Bug
Affects Versions: 3.6.5
Reporter: Bela Ban
Assignee: Bela Ban
Priority: Critical
Fix For: 3.6.6
At some point, {{TCP_NIO2}} starts dropping messages, at either the send or receive
direction (still need to find out). This shows itself when e.g. a JOIN fails: the joiner
sends a lot of {{JOIN-REQ}} messages and gets {{JOIN-RSP}} msgs from the coord, but
doesn't receive them.
If {{GMS.max_join_attempts="0"}}, then this goes on forever, or until the
joiner doesn't discover any nodes anymore.
{{probe.sh jmx=UNICAST3.printConnections}} shows that messages are sent but no acks are
received.
Clearing the connection table in {{TCP_NIO2}} fixes the problem: {{probe.sh
op=TCP_NIO2.clearConnections}}.
This shows that the issue is indeed in {{TCP_NIO2}}. Also, {{TCP}} and {{UDP}} work.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)