[infinispan-issues] [JBoss JIRA] (ISPN-6925) Race condition in staggered gets

Paul Ferraro (JIRA) issues at jboss.org
Tue Aug 16 13:02:00 EDT 2016


    [ https://issues.jboss.org/browse/ISPN-6925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13279882#comment-13279882 ] 

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}}.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


More information about the infinispan-issues mailing list