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

[Sanne Grinovero (JIRA)]

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

Sanne Grinovero commented on ISPN-573:
--------------------------------------

I'm a bit puzzled about this.
I always thought that async is great but only usable in some situations, depending on what the application is doing and what kind of consistency is required.
So if async is an option, you should use it for both local and wan replication, but if it's not an option, how could this be used in wan only?

Could anybody explain a use case in which this might make sense?

One case occurs to me, which is having a local cluster on which changes are performed, and a remote cluster which is just a readonly view to the same data - but  I assume this use case could be solved by setting up an async store and storing on the remote cluster?

> 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