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

[Manik Surtani (JIRA)]

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

Manik Surtani commented on ISPN-1910:
-------------------------------------

So you're suggesting any logic that forces a sync RPC when running in async mode (for the sake of state transfer) is invalid?  If that is the case then this should be targeted for 5.1.x as well.

And I presume in your last sentence in the description, you meant "disable" rather than "enable"?  ;)
                
> 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.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 enable 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