May 2014 - infinispan-issues - Jboss List Archives

[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

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

[JBoss JIRA] (ISPN-2324) Add user documentation for NSBT

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-2324?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-2324: ------------------------------ Fix Version/s: 7.0.0.Beta1 (was: 7.0.0.Alpha4) > Add user documentation for NSBT > -------------------------------- > > Key: ISPN-2324 > URL: https://issues.jboss.org/browse/ISPN-2324 > Project: Infinispan > Issue Type: Feature Request > Components: Documentation-Core > Affects Versions: 5.2.0.Alpha3 > Reporter: Mircea Markus > Assignee: Dan Berindei > Labels: documentation > Fix For: 7.0.0.Beta1 > > > To be linked from the user guide page:https://docs.jboss.org/author/display/ISPN/User+Guide -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2577) Silence SuspectExceptions

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-2577?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-2577: ------------------------------ Fix Version/s: 7.0.0.Beta1 (was: 7.0.0.Alpha4) > Silence SuspectExceptions > ------------------------- > > Key: ISPN-2577 > URL: https://issues.jboss.org/browse/ISPN-2577 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 5.2.0.Beta4, 6.0.0.Final > Reporter: Michal Linhard > Assignee: Dan Berindei > Priority: Critical > Fix For: 7.0.0.Beta1, 7.0.0.Final > > > There are lots of SuspectExceptions in resilience test run: > https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EDG6/view/EDG-REPOR... > We managed to keep these under cover for 5.1.x branch. > This is of course a cosmetic problem, but it polutes the log with unnecessary ERRORs. > Parsed logs here: > http://www.qa.jboss.com/~mlinhard/test_results/run54-parsed/ -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2857) Support asynchronous listeners and events with old values for JSR-107

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-2857?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-2857: ------------------------------ Fix Version/s: 7.0.0.Beta1 (was: 7.0.0.Alpha4) > Support asynchronous listeners and events with old values for JSR-107 > ---------------------------------------------------------------------- > > Key: ISPN-2857 > URL: https://issues.jboss.org/browse/ISPN-2857 > Project: Infinispan > Issue Type: Sub-task > Components: JCache, Listeners > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 7.0.0.Beta1 > > > These parts of the JSR-107 listener section are not currently tested by the TCK (version 0.6) -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2820) POST request with multipart/form-data encoding stores wrong content type

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-2820?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-2820: ------------------------------ Fix Version/s: 7.0.0.Beta1 (was: 7.0.0.Alpha4) > POST request with multipart/form-data encoding stores wrong content type > ------------------------------------------------------------------------ > > Key: ISPN-2820 > URL: https://issues.jboss.org/browse/ISPN-2820 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols > Affects Versions: 5.2.1.Final > Reporter: Dan Berindei > Assignee: Tristan Tarrant > Fix For: 7.0.0.Beta1 > > > The REST server uses the {{Content-Type}} header of the POST request to determine the content type of the stored entry. But with {{Content-Type: multipart/form-data}}, each parameter can have its own content type (and {{multipart/form-data}} is definitely not any parameter's content type). > This seems to be the way to do get the content type of each parameter: http://www.mkyong.com/webservices/jax-rs/file-upload-example-in-resteasy/ -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2854) REST server discards Content Encoding information from client

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-2854?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-2854: ------------------------------ Fix Version/s: 7.0.0.Beta1 (was: 7.0.0.Alpha4) > REST server discards Content Encoding information from client > ------------------------------------------------------------- > > Key: ISPN-2854 > URL: https://issues.jboss.org/browse/ISPN-2854 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols > Affects Versions: 5.2.2.Final > Reporter: NadirX > Fix For: 7.0.0.Beta1 > > > The REST server discards the Content-Encoding header from the client and therefore does not serve it back when the content is being read, possibly causing misinterpretation -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 5 months

1
0
0 / 0

[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

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues May 2014