[JBoss JIRA] (ISPN-263) Handle cluster partitions
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-263?page=com.atlassian.jira.plugin.s... ]
Pedro Ruivo updated ISPN-263:
-----------------------------
Fix Version/s: 7.0.0.Beta1
(was: 7.0.0.Alpha4)
> Handle cluster partitions
> -------------------------
>
> Key: ISPN-263
> URL: https://issues.jboss.org/browse/ISPN-263
> Project: Infinispan
> Issue Type: Feature Request
> Components: Core
> Reporter: Manik Surtani
> Assignee: Mircea Markus
> Labels: MERGE, roadmap, split_brain
> Fix For: 7.0.0.Beta1, 7.0.0.Final
>
>
> JGroups already detects split brains and issues a callback. The cache layer needs to decide what to do. The idea is to implement a few canned policies (restart, wipe, etc) and allow custom handlers to be attached as well.
> Analogous to JBCACHE-471
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
11 years, 11 months
[JBoss JIRA] (ISPN-2240) Per-key lock container leads to superfluous TimeoutExceptions on concurrent access to same key
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-2240?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-2240:
------------------------------
Fix Version/s: 7.0.0.Beta1
(was: 7.0.0.Alpha4)
> Per-key lock container leads to superfluous TimeoutExceptions on concurrent access to same key
> ----------------------------------------------------------------------------------------------
>
> Key: ISPN-2240
> URL: https://issues.jboss.org/browse/ISPN-2240
> Project: Infinispan
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 5.1.6.FINAL, 5.1.x
> Reporter: Robert Stupp
> Assignee: Mircea Markus
> Priority: Critical
> Fix For: 7.0.0.Beta1, 7.0.0.Final
>
> Attachments: ISPN-2240_fix_TimeoutExceptions.patch, somehow.zip
>
>
> Hi,
> I've encountered a lot of TimeoutExceptions just running a load test against an infinispan cluster.
> I tracked down the reason and found out, that the code in org.infinispan.util.concurrent.locks.containers.AbstractPerEntryLockContainer#releaseLock() causes these superfluous TimeoutExceptions.
> A small test case (which just prints out timeouts, too late timeouts and "paints" a lot of dots to the console - more dots/second on the console means better throughput ;-)
> In a short test I extended the class ReentrantPerEntryLockContainer and changed the implementation of releaseLock() as follows:
> {noformat}
> public void releaseLock(Object lockOwner, Object key) {
> ReentrantLock l = locks.get(key);
> if (l != null) {
> if (!l.isHeldByCurrentThread())
> throw new IllegalStateException("Lock for [" + key + "] not held by current thread " + Thread.currentThread());
> while (l.isHeldByCurrentThread())
> unlock(l, lockOwner);
> if (!l.hasQueuedThreads())
> locks.remove(key);
> }
> else
> throw new IllegalStateException("No lock for [" + key + ']');
> }
> {noformat}
> The main improvement is that locks are not removed from the concurrent map as long as other threads are waiting on that lock.
> If the lock is removed from the map while other threads are waiting for it, they may run into timeouts and force TimeoutExceptions to the client.
> The above methods "paints more dots per second" - means: it gives a better throughput for concurrent accesses to the same key.
> The re-implemented method should also fix some replication timeout exceptions.
> Please, please add this to 5.1.7, if possible.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
11 years, 11 months
[JBoss JIRA] (ISPN-2034) Add backwards serialization compatibility tests
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-2034?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-2034:
------------------------------
Fix Version/s: 7.0.0.Beta1
(was: 7.0.0.Alpha4)
> Add backwards serialization compatibility tests
> -----------------------------------------------
>
> Key: ISPN-2034
> URL: https://issues.jboss.org/browse/ISPN-2034
> Project: Infinispan
> Issue Type: Enhancement
> Components: Marshalling
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Labels: compatibility
> Fix For: 7.0.0.Beta1
>
>
> Take each existing minor branch, i.e. 4.1.x, 4.0.x,...etc and modify VersionAwareMarshallerTest so that payloads are stored in a data file.
> Then, take data files for each branch and store in git (master and 5.1.x), and try reading them with the existing externalizer/marshalling set up.
> It should work...
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
11 years, 11 months
[JBoss JIRA] (ISPN-2342) Cross-Site Replication: State Transfer between sites
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-2342?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-2342:
------------------------------
Fix Version/s: 7.0.0.Beta1
(was: 7.0.0.Alpha4)
> Cross-Site Replication: State Transfer between sites
> ----------------------------------------------------
>
> Key: ISPN-2342
> URL: https://issues.jboss.org/browse/ISPN-2342
> Project: Infinispan
> Issue Type: Feature Request
> Components: Cross-Site Replication
> Affects Versions: 6.0.1.Final
> Reporter: Erik Salter
> Assignee: Pedro Ruivo
> Labels: roadmap
> Fix For: 7.0.0.Beta1, 7.0.0.Final
>
>
> To bring up a new site or recover a failed site, I need an inter-site state transfer mechanism for synchronizing keys.
> Note that initially, this should a manual process that is invoked on one site to one of its configured backups.
> This should be based on the non-blocking state transfer mechanism for consistency.
> The pseudo-design may look similar to the following:
> - Manually invokable, background thread
> - Since the bridge end is open, there are writes happening to keys. Keep track of the puts/removes on the main data owner.
> - Iterate through the key set.
> - If the key has already been modified since the process started, discard.
> - Else synchronously write the key value in a TX context
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
11 years, 11 months