[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:all-tabpanel ]

Dan Berindei updated ISPN-1910:
-------------------------------

         Description: 
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.

  was:
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.

    Git Pull Request: https://github.com/infinispan/infinispan/pull/998  (was: https://github.com/infinispan/infinispan/pull/998)

    
> 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