[infinispan-issues] [JBoss JIRA] (ISPN-1910) State transfer should not force all invocations to be synchronous

[Dan Berindei (JIRA)]

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

Dan Berindei commented on ISPN-1910:
------------------------------------

I'm not aware for any other logic forcing a sync RPC besides replay support. 

After Bela brought up this link I searched a bit and I'm pretty sure that replay is no longer useful (since we stopped replying with RequestIgnoredResponse or ExtendedResponse). However, if there is any other logic forcing sync RPCs, we should evaluate it separately.

For instance, StateTransferInProgressExceptions are not thrown when the cache is in async mode - so there is no need to make all RPCs synchronous in order to catch these exceptions. But remote CommitCommands can still return RESEND_PREPARE, so if the set of targets has changed the RPC needs to be synchronous.

I fixed the last sentence and I added 5.1.x as fix version.
                
> State transfer should not force all invocations to be synchronous
> -----------------------------------------------------------------
>
>                 Key: ISPN-1910
>                 URL: https://issues.jboss.org/browse/ISPN-1910
>             Project: Infinispan
>          Issue Type: Bug
>          Components: RPC
>    Affects Versions: 5.1.2.FINAL
>            Reporter: Dan Berindei
>            Assignee: Dan Berindei
>             Fix For: 5.1.x, 5.2.0.ALPHA1, 5.2.0.FINAL
>
>
> This is a reedit of ISPN-835, only now it affects both repl and dist caches as a result of my ISPN-1475 fix. All invocations are supported because enabling state transfer also enables replay support, but there is no reason to support replay at the transport level any more. 
> Before ISPN-1194, a cache could receive RPCs before it had received its initial state, and it would reply with a RequestIgnoredResponse. The originator would see this response and retry the operation, without any change. 
> After ISPN-1194, we no longer use RequestIgnoredResponse - instead a node can reply with a StateTransferInProgressException to signal that the command targets may have changed or (only for CommitCommands) with CommitCommand.RESEND_PREPARE to request the prepare information on a new owner. Either way, there is no case where the originator has to resend the command exactly the same as the first time.
> We should disable the replay support completely, as this job is better handled at a higher level.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira