[JBoss JIRA] (ISPN-1824) Cross-datacentre distribution
by Manik Surtani (JIRA)
Manik Surtani created ISPN-1824:
-----------------------------------
Summary: Cross-datacentre distribution
Key: ISPN-1824
URL: https://issues.jboss.org/browse/ISPN-1824
Project: Infinispan
Issue Type: Feature Request
Components: Distributed Cache
Affects Versions: 5.1.0.FINAL
Reporter: Manik Surtani
Assignee: Mircea Markus
Priority: Blocker
Fix For: 5.2.0.ALPHA1, 5.2.0.FINAL
There are currently two designs for this:
1. Use JGroups' RELAY for master/master.
2. Use an Infinispan-only setup using Hot Rod and an async RemoteCacheStore
Both design patterns should be documented, tested, benchmarked. Should survive failures in relaying node, on either datacentre.
Initially test on 2 datacentres, and if possible on 3.
--
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
13 years, 6 months
[JBoss JIRA] (ISPN-2186) Coordinator tries to install new view after graceful shutdown
by Michal Linhard (JIRA)
Michal Linhard created ISPN-2186:
------------------------------------
Summary: Coordinator tries to install new view after graceful shutdown
Key: ISPN-2186
URL: https://issues.jboss.org/browse/ISPN-2186
Project: Infinispan
Issue Type: Bug
Affects Versions: 5.1.6.FINAL (JDG)
Reporter: Michal Linhard
Assignee: Manik Surtani
Priority: Minor
This is not a serious problem, because so far the only thing I discoverd it causes is a superfluous debug level log message.
This happened in elasticity tests with radargun,
In these tests we go from 4 nodes to 8 and back to 4.
See views installed:
http://www.qa.jboss.com/~mlinhard/hyperion2/run218-radargun-08-elasticity...
In this case, each time the node is shutdown it is the coordinator (I'm not sure whether this is accident or coordinators are picked by their seniority in the cluster)
The shutdown is made gracefully via DefaultCacheManager.stop() and each time this happens I can see an attempt of CacheViewsManagerImpl to install a new view - which doesn't complete because the coordinator shuts down few moments later and the new view is really established by a new coordinator.
Log from slave on node0003:
{code}
02:37:32,737 INFO [org.radargun.stages.KillStage] (pool-1-thread-1) Tearing down cache wrapper.
02:38:02,752 WARN [org.infinispan.transaction.TransactionTable] (pool-1-thread-1) ISPN000100: Stopping, but there are 9 local transactions and 0 remote transactions that did not finish in time.
02:38:02,755 DEBUG [org.infinispan.cacheviews.CacheViewsManagerImpl] (CacheViewInstaller-3,hyperion1098-55173) Installing new view CacheView{viewId=9, members=[hyperion1099-41789, hyperion1097-42149, hyperion1100-42888, hyperion1102-1099, hyperion1101-56019, hyperion1103-38655, hyperion1096-46484]} for cache x
02:38:04,279 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (pool-1-thread-1) ISPN000080: Disconnecting and closing JGroups Channel
02:38:04,641 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (pool-1-thread-1) ISPN000082: Stopping the RpcDispatcher
02:38:04,816 INFO [org.radargun.Slave] (pool-1-thread-1) Finished stage: KillStage {tearDown=true, productName='jdg60', useSmartClassLoading=true, slaveIndex=0, activeSlavesCount=8, totalSlavesCount=8, slaves=[0]}
02:38:04,817 INFO [org.radargun.Slave] (main) Ack successfully sent to the master
{code}
--
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
13 years, 6 months