January 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-2704) AsyncStoreTest.testRestrictionOnAddingToAsyncQueue still fails randomly

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-2704?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-2704: ----------------------------------- Fix Version/s: 5.2.0.CR2 (was: 5.2.0.Final) > AsyncStoreTest.testRestrictionOnAddingToAsyncQueue still fails randomly > ----------------------------------------------------------------------- > > Key: ISPN-2704 > URL: https://issues.jboss.org/browse/ISPN-2704 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Labels: testsuite_stability > Fix For: 5.2.0.CR2 > > > {code}testRestrictionOnAddingToAsyncQueue(org.infinispan.loaders.decorators.AsyncStoreTest) Time elapsed: 0.05 sec <<< FAILURE! > org.infinispan.CacheException: AsyncStore stopped; no longer accepting more entries. > at org.infinispan.loaders.decorators.AsyncStore$State.put(AsyncStore.java:401) > at org.infinispan.loaders.decorators.AsyncStore.put(AsyncStore.java:140) > at org.infinispan.loaders.decorators.AsyncStore.remove(AsyncStore.java:243) > at org.infinispan.loaders.decorators.AsyncStoreTest.doTestRemove(AsyncStoreTest.java:421) > at org.infinispan.loaders.decorators.AsyncStoreTest.testRestrictionOnAddingToAsyncQueue(AsyncStoreTest.java:147) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80) > at org.testng.internal.InvokeMethodRunnable.runOne(InvokeMethodRunnable.java:46) > at org.testng.internal.InvokeMethodRunnable.run(InvokeMethodRunnable.java:37) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) > at java.util.concurrent.FutureTask.run(FutureTask.java:138) > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) > at java.lang.Thread.run(Thread.java:680){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

13 years, 3 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 commented on ISPN-2240: ------------------------------------- [~snazy] How does it look on 5.2.0.CR1? > 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: Locking and Concurrency > Affects Versions: 5.1.6.FINAL, 5.1.x > Reporter: Robert Stupp > Assignee: Mircea Markus > Priority: Critical > Fix For: 5.2.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

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2701) Spring ConfigurationOverridesTest, InfinispanEmbeddedCacheManagerDefinitionTest and InfinispanContainerCacheManagerDefinitionTest fail

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-2701?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-2701: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Spring ConfigurationOverridesTest, InfinispanEmbeddedCacheManagerDefinitionTest and InfinispanContainerCacheManagerDefinitionTest fail > -------------------------------------------------------------------------------------------------------------------------------------- > > Key: ISPN-2701 > URL: https://issues.jboss.org/browse/ISPN-2701 > Project: Infinispan > Issue Type: Bug > Components: Spring integration, Test Suite > Affects Versions: 5.2.0.Beta6 > Reporter: Dan Berindei > Assignee: Mircea Markus > Priority: Critical > Fix For: 5.2.0.CR2 > > > ConfigurationOverridesTest wasn't running because it was missing the @Test annotation (see ISPN-2534). I added the annotation, but now many of its methods are failing because of configuration changes. -- 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

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2326) c3p0 not part of the release

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-2326?page=com.atlassian.jira.plugin.... ] Adrian Nistor commented on ISPN-2326: ------------------------------------- Actually after careful reading of maven user guide this is not a bug. Their docs warn about unpredictable results if a dependency is included transitively via multiple paths. In this case c3p0 dependency appears twice, jdbc cachestore module depends on it in compile scope and lucene-directory in test scope. Only the fist dependency path is considered by assembly plugin. And if the first one happens to have 'test' scope that means the dependency won't make it into the final assembly. That's why the order of modules matters. Unfortunately changing the order of modules can fix c3p0 but leads to other deps being ignored, so we're not solving anything this way. We'll have to ask a maven guru. > c3p0 not part of the release > ---------------------------- > > Key: ISPN-2326 > URL: https://issues.jboss.org/browse/ISPN-2326 > Project: Infinispan > Issue Type: Bug > Components: Build process > Affects Versions: 5.2.0.Alpha4 > Reporter: Thomas Fromm > Assignee: Adrian Nistor > Priority: Critical > Fix For: 5.2.0.Final > > > According infinispan-5.2.0.Alpha4-all/modules/cachestores/jdbc/runtime-classpath.txt c3p0 lib should be part of the release. -- 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

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2697) HotRodServer startup fails when its record cannot be inserted into topology cache

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2697?page=com.atlassian.jira.plugin.... ] Mircea Markus commented on ISPN-2697: ------------------------------------- "if the message gets lost and there's no following broadcasted message, the message will be not retransmitted and the put operation times out" <-- even if there's no other message sent, STABLE should notice that at some point and realize and force a retransmission. > HotRodServer startup fails when its record cannot be inserted into topology cache > --------------------------------------------------------------------------------- > > Key: ISPN-2697 > URL: https://issues.jboss.org/browse/ISPN-2697 > Project: Infinispan > Issue Type: Bug > Components: Remote protocols > Affects Versions: 5.2.0.Beta6 > Reporter: Radim Vansa > Assignee: Galder Zamarreño > > When the HotRodServer starts it inserts its record to __hotRodTopologyCache ({{HotRodServer.addSelfToTopologyView(...)}}). > However, this put may very easily fail - as the command is broadcasted using NAKACK2 protocol, if the message gets lost and there's no following broadcasted message, the message will be not retransmitted and the put operation times out (Replication timeout), which fails the whole HotRodServer startup, all because of one lost UDP message. -- 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

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2697) HotRodServer startup fails when its record cannot be inserted into topology cache

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2697?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2697: -------------------------------- Fix Version/s: 5.3.0.Final > HotRodServer startup fails when its record cannot be inserted into topology cache > --------------------------------------------------------------------------------- > > Key: ISPN-2697 > URL: https://issues.jboss.org/browse/ISPN-2697 > Project: Infinispan > Issue Type: Bug > Components: Remote protocols > Affects Versions: 5.2.0.Beta6 > Reporter: Radim Vansa > Assignee: Galder Zamarreño > Fix For: 5.3.0.Final > > > When the HotRodServer starts it inserts its record to __hotRodTopologyCache ({{HotRodServer.addSelfToTopologyView(...)}}). > However, this put may very easily fail - as the command is broadcasted using NAKACK2 protocol, if the message gets lost and there's no following broadcasted message, the message will be not retransmitted and the put operation times out (Replication timeout), which fails the whole HotRodServer startup, all because of one lost UDP message. -- 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

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2693) ByteArrayKey should print out its hashCode

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2693?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2693: -------------------------------- Fix Version/s: 5.3.0.Final > ByteArrayKey should print out its hashCode > ------------------------------------------ > > Key: ISPN-2693 > URL: https://issues.jboss.org/browse/ISPN-2693 > Project: Infinispan > Issue Type: Bug > Components: Marshalling > Affects Versions: 5.2.0.Beta6 > Reporter: Radim Vansa > Assignee: Galder Zamarreño > Priority: Minor > Fix For: 5.3.0.Final > > > When a ByteArrayKey is printed out, the format is {{ByteArrayKey{data=ByteArray{size=..., hashCode=..., array=...}}}} > However, ByteArray computes hashCode using array.hashCode() instead of Arrays.hashCode(array) and, therefore, two equal ByteArrayKeys have different hashCode when printed out. > Another way to fix that could be using Arrays.hashCode(array) in Util.printArray() (although I am not sure whether this could break anything). > As the result is pretty unexpected, I consider this a bug rather than a feature request. -- 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

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2699) Failed ping on startup can leave socket dirty

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2699?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2699: -------------------------------- Fix Version/s: 5.3.0.Final > Failed ping on startup can leave socket dirty > --------------------------------------------- > > Key: ISPN-2699 > URL: https://issues.jboss.org/browse/ISPN-2699 > Project: Infinispan > Issue Type: Bug > Components: Remote protocols > Affects Versions: 5.2.0.Beta6 > Reporter: Radim Vansa > Assignee: Galder Zamarreño > Fix For: 5.3.0.Final > > > Ping on startup in TransportObjectFactory.makeObject does not check the return value of ping operation, neither the tcpTransport.isValid(). > Therefore, if a HotRodClientException is thrown when the response header is read from socket, the socket is left in a dirty state. > In our case this resulted in reading response to previous request (the request was written but the response was not read due to some timeout and then, when another request was executed it read the response to the first request). This caused {{ISPN004004: Invalid message id. Expected 2930 and received 212}} -- 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

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2632) Uneven request balancing after node crash

by Michal Linhard (JIRA)

[ https://issues.jboss.org/browse/ISPN-2632?page=com.atlassian.jira.plugin.... ] Michal Linhard commented on ISPN-2632: -------------------------------------- no that's the thing, we don't have yet JDG ER with 5.2.0.CR1 inside. > Uneven request balancing after node crash > ----------------------------------------- > > Key: ISPN-2632 > URL: https://issues.jboss.org/browse/ISPN-2632 > Project: Infinispan > Issue Type: Bug > Components: Remote protocols > Affects Versions: 5.2.0.CR1 > Reporter: Michal Linhard > Assignee: Galder Zamarreño > Priority: Blocker > Fix For: 5.2.0.Final > > > This is a new manifestation of ISPN-1995, but in this case this happens after killing only one node: the hot rod requests aren't very well balanced. > these runs still manifest also ISPN-2550 and it may be cause of this bug. > The uneven balancing of requests can be seen here: > https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EDG6/view/EDG-REPOR... -- 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

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2632) Uneven request balancing after node crash

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2632?page=com.atlassian.jira.plugin.... ] Mircea Markus commented on ISPN-2632: ------------------------------------- the sooner the better as this is a blocker. That would run 5.2.CR1, right? > Uneven request balancing after node crash > ----------------------------------------- > > Key: ISPN-2632 > URL: https://issues.jboss.org/browse/ISPN-2632 > Project: Infinispan > Issue Type: Bug > Components: Remote protocols > Affects Versions: 5.2.0.CR1 > Reporter: Michal Linhard > Assignee: Galder Zamarreño > Priority: Blocker > Fix For: 5.2.0.Final > > > This is a new manifestation of ISPN-1995, but in this case this happens after killing only one node: the hot rod requests aren't very well balanced. > these runs still manifest also ISPN-2550 and it may be cause of this bug. > The uneven balancing of requests can be seen here: > https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EDG6/view/EDG-REPOR... -- 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

13 years, 3 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 January 2013