[
https://issues.jboss.org/browse/ISPN-6925?page=com.atlassian.jira.plugin....
]
Radim Vansa commented on ISPN-6925:
-----------------------------------
I think this could be solved by replacing RspList by a structure like Map<Address,
RspWrapper> where RspWrapper would have field {{volatile Rsp}} - the Rsp would be
published then atomically, instead of non-atomic copy.
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: Dan Berindei
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}}.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)