]
Paul Ferraro commented on ISPN-6925:
------------------------------------
[~rvansa] Your commits do not cherry-pick cleanly into 8.2.x - so you'll need to
create separate branch that integrates these commits based on 8.2.x (as well as a separate
PR). That's far easier for me than to reproduce the specific conditions in a unit
test.
FYI, TRACE logging was configured for "org.jgroups". The reason you see no
trace logs is that FORK doesn't log anything below WARN (other than during state
transfer).
Race condition in staggered gets
--------------------------------
Key: ISPN-6925
URL:
https://issues.jboss.org/browse/ISPN-6925
Project: Infinispan
Issue Type: Bug
Components: Core
Affects Versions: 9.0.0.Alpha3, 8.2.3.Final
Reporter: Radim Vansa
Assignee: Radim Vansa
Priority: Critical
Attachments: server.log.node1, server.log.node2, server.log.node3
There's a race condition in {{CommandAwareRpcDispatcher}}, as we do staggered gets.
When the {{RspList}} is prepared, and then in {{processCallsStaggered$lambda}} the {{Rsp}}
is filled in - both of them can set is as received but later see that the other response
was not received yet, because there's no memory barrieri n between the
{{setValue}}/{{setException}} and checking {{wasReceived}}.
The race above happens when two responses come but none of them is accepted by the
filter, but there's a second one in JGroupsTransport when the first response is
accepted but then comes another one. In {{JGroupsTransport.invokeRemotelyAsync}} in the
lambda handling {{rspListFuture.thenApply}} we may see another thread concurrently
modifying the rsps; e.g. in {{checkRsp}} you find out that the concurrently written
response was received and it's not an exception according to flags, but the value will
be null, so you return null while you can have valid response in the other {{Rsp}}.