April 2014 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-2849) Don't keep threads blocked when waiting for locks to be released

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-2849?page=com.atlassian.jira.plugin.... ] Work on ISPN-2849 started by Pedro Ruivo. > Don't keep threads blocked when waiting for locks to be released > ---------------------------------------------------------------- > > Key: ISPN-2849 > URL: https://issues.jboss.org/browse/ISPN-2849 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Affects Versions: 6.0.0.CR1 > Reporter: Mircea Markus > Assignee: Pedro Ruivo > > ATM if a tx2 waits on a lock to be released by tx1, the (incoming) tx2 thread is BLOCKED and taken out from the pool. A better way to implement this is by using a structure that would hold and order the depending transactions on the receiver correlated with the async execution API from JGroups 3.3.0, result being that tx2 would not BLOCK but return to the pool this (not maxing out the thread pool that executes commands). > More about it in the "Async invocation section" of https://docspace.corp.redhat.com/docs/DOC-134411 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4192) Adding a clustered in a local cache fails with NullPointerException

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-4192?page=com.atlassian.jira.plugin.... ] Galder Zamarreño reassigned ISPN-4192: -------------------------------------- Assignee: Galder Zamarreño (was: William Burns) > Adding a clustered in a local cache fails with NullPointerException > ------------------------------------------------------------------- > > Key: ISPN-4192 > URL: https://issues.jboss.org/browse/ISPN-4192 > Project: Infinispan > Issue Type: Bug > Affects Versions: 7.0.0.Alpha2 > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 7.0.0.Alpha4 > > > members is null > {code} > Caused by: java.lang.NullPointerException > at org.infinispan.notifications.cachelistener.CacheNotifierImpl.addedListener(CacheNotifierImpl.java:594) > at org.infinispan.notifications.impl.AbstractListenerImpl.validateAndAddListenerInvocation(AbstractListenerImpl.java:154) > at org.infinispan.notifications.cachelistener.CacheNotifierImpl.addListener(CacheNotifierImpl.java:578) > at org.infinispan.cache.impl.CacheImpl.addListener(CacheImpl.java:560) > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4192) Adding a clustered in a local cache fails with NullPointerException

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-4192?page=com.atlassian.jira.plugin.... ] Galder Zamarreño commented on ISPN-4192: ---------------------------------------- [~william.burns], it's getting ackward developing the remote event stuff without a fix for this, because there's no metadata information available in the local listeners, and want to verify data versions, which are retrieved from metadata, match up. So, I'll assign this to me and give it a crack :) > Adding a clustered in a local cache fails with NullPointerException > ------------------------------------------------------------------- > > Key: ISPN-4192 > URL: https://issues.jboss.org/browse/ISPN-4192 > Project: Infinispan > Issue Type: Bug > Affects Versions: 7.0.0.Alpha2 > Reporter: Galder Zamarreño > Assignee: William Burns > Fix For: 7.0.0.Alpha4 > > > members is null > {code} > Caused by: java.lang.NullPointerException > at org.infinispan.notifications.cachelistener.CacheNotifierImpl.addedListener(CacheNotifierImpl.java:594) > at org.infinispan.notifications.impl.AbstractListenerImpl.validateAndAddListenerInvocation(AbstractListenerImpl.java:154) > at org.infinispan.notifications.cachelistener.CacheNotifierImpl.addListener(CacheNotifierImpl.java:578) > at org.infinispan.cache.impl.CacheImpl.addListener(CacheImpl.java:560) > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-1986) Make putForExternalRead return a boolean instead of void

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-1986?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-1986: -------------------------------- Fix Version/s: 7.0.0.Alpha4 (was: 7.0.0.Alpha3) > Make putForExternalRead return a boolean instead of void > -------------------------------------------------------- > > Key: ISPN-1986 > URL: https://issues.jboss.org/browse/ISPN-1986 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Priority: Critical > Fix For: 7.0.0.Alpha4, 7.0.0.Final > > > Related to ISPN-1983 and https://hibernate.onjira.com/browse/HHH-7256, I'd like to change the API of putForExternalRead() to return a boolean instead of void. > The reason for doing this is to be able to find out if the PFER did actually end up storing something or not. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2342) Cross-Site Replication: State Transfer between sites

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2342?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2342: -------------------------------- Fix Version/s: 7.0.0.Alpha4 (was: 7.0.0.Alpha3) > 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.Alpha4, 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 12 months

1
0
0 / 0

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

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2324?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2324: -------------------------------- Fix Version/s: 7.0.0.Alpha4 (was: 7.0.0.Alpha3) > 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.Alpha4 > > > To be linked from the user guide page:https://docs.jboss.org/author/display/ISPN/User+Guide -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2034) Add backwards serialization compatibility tests

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2034?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2034: -------------------------------- Fix Version/s: 7.0.0.Alpha4 (was: 7.0.0.Alpha3) > 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.Alpha4 > > > 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2240) Per-key lock container leads to superfluous TimeoutExceptions on concurrent access to same key

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2240?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2240: -------------------------------- Fix Version/s: 7.0.0.Alpha4 (was: 7.0.0.Alpha3) > 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.Alpha4, 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2577) Silence SuspectExceptions

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2577?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2577: -------------------------------- Fix Version/s: 7.0.0.Alpha4 (was: 7.0.0.Alpha3) > 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.Alpha4, 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 12 months

1
0
0 / 0

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

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2820?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2820: -------------------------------- Fix Version/s: 7.0.0.Alpha4 (was: 7.0.0.Alpha3) > 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.Alpha4 > > > 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 12 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues April 2014