[
https://jira.jboss.org/browse/ISPN-573?page=com.atlassian.jira.plugin.sys...
]
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