[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)
10 years, 5 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)
10 years, 5 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)
10 years, 5 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)
10 years, 5 months
[JBoss JIRA] (ISPN-2956) putIfAbsent on Hot Rod Java client doesn't reliably fulfil contract
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-2956?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-2956:
------------------------------
Fix Version/s: 7.0.0.Beta1
(was: 7.0.0.Alpha4)
> putIfAbsent on Hot Rod Java client doesn't reliably fulfil contract
> -------------------------------------------------------------------
>
> Key: ISPN-2956
> URL: https://issues.jboss.org/browse/ISPN-2956
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Protocols
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Priority: Minor
> Labels: hotrod-java-client, remote-clients
> Fix For: 7.0.0.Beta1
>
>
> Hot Rod's putIfAbsent might have issues on some edge cases:
> {quote}I want to know whether the putting entry already exists in the remote
> cache cluster, or not.
> I thought that RemoteCache.putIfAbsent() would be useful for that
> purpose, i.e.,
> {code}
> if (remoteCache.putIfAbsent(k,v) == null) {
> // new entry.
> } else {
> // k already exists.
> }
> {code}
> But no.
> The putIfAbsent() for new entry may return non-null value, if one of the
> server crushed while putting.
> The behavior is like the following:
> 1. Client do putIfAbsent(k,v).
> 2. The server receives the request and sends replication requests to
> other servers. If the server crushed before completing replication, some
> servers own that (k,v), but others not.
> 3. Client receives the error. The putIfAbsent() internally retries the
> same request to the next server in the cluster server list.
> 4. If the next server owns the (k,v), the putIfAbsent() returns the
> replicated (k,v) at the step 2, without any error.
> So, putIfAbsent() is not reliable for knowing whether the putting entry
> is *exactly* new or not.
> Does anyone have any idea/workaround for this purpose?{quote}
> A workaround is to do this:
> {quote}We got a simple solution, which can be applied to our customer's application.
> If each value part of putting (k,v) is unique or contains unique value,
> the client can do *double check* wether the entry is new.
> {code}
> val = System.nanoTime(); // or uuid is also useful.
> if ((ret = cache.putIfAbsent(key, val)) == null
> || ret.equals(val)) {
> // new entry, if the return value is just the same.
> } else {
> // key already exists.
> }
> {code}
> We are proposing this workaround which almost works fine.{quote}
> However, this is a bit of a cludge.
> Hot Rod should be improved with an operation that allows a version to be passed when entry is created, instead of relying on the client generating it.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 5 months