[infinispan-issues] [JBoss JIRA] Commented: (ISPN-573) Allow LAN RPCs to be SYNC while WAN RPCs to be ASYNC

[Manik Surtani (JIRA)]

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

Manik Surtani commented on ISPN-573:
------------------------------------

The remote cluster could be a backup cluster.  In this case it doesn't have the same consistency requirements as the LAN.

> Allow LAN RPCs to be SYNC while WAN RPCs to be ASYNC
> ----------------------------------------------------
>
>                 Key: ISPN-573
>                 URL: https://jira.jboss.org/browse/ISPN-573
>             Project: Infinispan
>          Issue Type: Feature Request
>          Components: RPC
>    Affects Versions: 4.1.0.CR2
>            Reporter: Manik Surtani
>            Assignee: Manik Surtani
>             Fix For: 5.1.0.BETA1, 5.1.0.Final
>
>
> This will allow for interesting WAN architectures where RPC messages to members within the same LAN would be sent synchronously and RPC messages to remote members across a WAN to be sent asynchronously.  This will allow for a cluster to span 2 data centres, (configured using TCP, for example), while allowing for *some* backups to be in the same data centre while others reside in a remote data centre.
> From an email thread:
> "So even if you have 4 owners, 2 in each DC, the "local" replication, 
> there will be no way to write to the local backup synchronously and 
> the remote backups asynchronously. I.e., either all comms are sync or 
> all comms are async.
> Maybe this is something we can add in Infinispan. I.e., with node 
> hints (https://jira.jboss.org/browse/ISPN-180) (*) we could detect 
> which recipients are local and which are remote, and accordingly split 
> the RPC into 2: a sync local RPC and an async remote RPC.
> (*) Node hinting isn't strictly necessary; the naming convention you 
> mentioned earlier would work in this regard as well, although I think 
> these hints is probably a better universal solution since we need this 
> for other things anyway."

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira