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

[Manik Surtani (JIRA)]

     [ https://issues.jboss.org/browse/ISPN-573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Manik Surtani updated ISPN-573:
-------------------------------

    Fix Version/s: 6.0.0.Final
                       (was: 5.1.0.BETA1)
                       (was: 5.1.0.Final)


> Allow LAN RPCs to be SYNC while WAN RPCs to be ASYNC
> ----------------------------------------------------
>
>                 Key: ISPN-573
>                 URL: https://issues.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
>              Labels: datacentre_replication, wan, wan_replication
>             Fix For: 6.0.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.
For more information on JIRA, see: http://www.atlassian.com/software/jira