March 2014 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-3956) L1WriteSynchronizer can cause locking with concurrent gets when value is not present

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3956?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3956: -------------------------------- Labels: 630 (was: ) > L1WriteSynchronizer can cause locking with concurrent gets when value is not present > ------------------------------------------------------------------------------------ > > Key: ISPN-3956 > URL: https://issues.jboss.org/browse/ISPN-3956 > Project: Infinispan > Issue Type: Bug > Components: L1 > Affects Versions: 6.0.0.Final > Reporter: William Burns > Assignee: William Burns > Labels: 630 > Fix For: 7.0.0.Alpha1, 7.0.0.Final > > > This has been seen previously only on IBM JDK 6 ISPN-3889, however an end user also now can reproduce this issue https://community.jboss.org/thread/236590 > The issue is that we don't set the remote lookup value to be null when nothing is found and thus any threads that are waiting for the remote lookup were never notified of this. -- 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

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-3920) Server initialization race condition - cache config defaults not used

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3920?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3920: -------------------------------- Assignee: Ion Savin (was: Mircea Markus) > Server initialization race condition - cache config defaults not used > --------------------------------------------------------------------- > > Key: ISPN-3920 > URL: https://issues.jboss.org/browse/ISPN-3920 > Project: Infinispan > Issue Type: Bug > Components: Server > Affects Versions: 6.0.1.Final > Reporter: Ion Savin > Assignee: Ion Savin > Fix For: 7.0.0.Alpha1, 7.0.0.Final > > Attachments: server.log.gz > > > The [simple|https://github.com/infinispan/cpp-client/blob/master/test/Simple.cpp] HRCPP unit tests puts a key/value pair into the default cache and then retrives the value to make sure it's the same. Running the test on a single CPU machine against 6.0.0.Final causes the test to fail. > The root cause seems to be a race-condition in service initialization. The ProtocolServerServices are initialized (and create cache intances) before the CacheConfigurationServices finish loading the cache configuration defaults. Because of this AnyEquivalence is used for both keys and values instead of AnyServerEquivalence. -- 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

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-3920) Server initialization race condition - cache config defaults not used

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3920?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3920: -------------------------------- Labels: 630 (was: ) > Server initialization race condition - cache config defaults not used > --------------------------------------------------------------------- > > Key: ISPN-3920 > URL: https://issues.jboss.org/browse/ISPN-3920 > Project: Infinispan > Issue Type: Bug > Components: Server > Affects Versions: 6.0.1.Final > Reporter: Ion Savin > Assignee: Ion Savin > Labels: 630 > Fix For: 7.0.0.Alpha1, 7.0.0.Final > > Attachments: server.log.gz > > > The [simple|https://github.com/infinispan/cpp-client/blob/master/test/Simple.cpp] HRCPP unit tests puts a key/value pair into the default cache and then retrives the value to make sure it's the same. Running the test on a single CPU machine against 6.0.0.Final causes the test to fail. > The root cause seems to be a race-condition in service initialization. The ProtocolServerServices are initialized (and create cache intances) before the CacheConfigurationServices finish loading the cache configuration defaults. Because of this AnyEquivalence is used for both keys and values instead of AnyServerEquivalence. -- 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

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-3932) FineGrainedAtomicMap with REPEATABLE_READ sees modifications from other transactions

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3932?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3932: -------------------------------- Labels: 621 630 (was: 621) > FineGrainedAtomicMap with REPEATABLE_READ sees modifications from other transactions > ------------------------------------------------------------------------------------ > > Key: ISPN-3932 > URL: https://issues.jboss.org/browse/ISPN-3932 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 5.2.7.Final, 6.0.1.Final > Reporter: Dan Berindei > Assignee: Pedro Ruivo > Labels: 621, 630 > Fix For: 7.0.0.Alpha1, 7.0.0.Final > > > FineGrainedAtomicMap doesn't respect the REPEATABLE_READ isolation level: a transaction holding a FGAM reference will see subkeys added by another concurrent transaction. > A test with PESSIMISTIC locking is here: https://github.com/danberindei/infinispan/commit/526ae4c414009b2a95b39a65... > We need to test OPTIMISTIC locking and the coarse-grained AtomicMap as well. -- 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

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-3943) Fix L1WriteSynchronizerTest failures

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3943?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3943: -------------------------------- Labels: 630 (was: ) > Fix L1WriteSynchronizerTest failures > ------------------------------------ > > Key: ISPN-3943 > URL: https://issues.jboss.org/browse/ISPN-3943 > Project: Infinispan > Issue Type: Bug > Reporter: William Burns > Assignee: William Burns > Labels: 630 > Fix For: 7.0.0.Alpha1, 7.0.0.Final > > > The test L1WriteSynchronizerTest.testSpawnedThreadBlockingExceptionTimeWait failed previously, This is to make sure this test doesn't fail in the future. > http://ci.infinispan.org/project.html?projectId=Infinispan&testNameId=242... -- 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

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-3944) DistSyncL1RepeatableReadFuncTest.testNoEntryInL1GetWithConcurrentReplace random failures

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3944?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3944: -------------------------------- Labels: 630 testsuite_stability (was: testsuite_stability) > DistSyncL1RepeatableReadFuncTest.testNoEntryInL1GetWithConcurrentReplace random failures > ---------------------------------------------------------------------------------------- > > Key: ISPN-3944 > URL: https://issues.jboss.org/browse/ISPN-3944 > Project: Infinispan > Issue Type: Bug > Components: Core, Test Suite - Core > Affects Versions: 6.0.1.Final > Reporter: Dan Berindei > Assignee: William Burns > Labels: 630, testsuite_stability > Fix For: 7.0.0.Alpha1, 7.0.0.Final > > Attachments: dsl1rrft.log.gz > > > Random failure in DistSyncL1RepeatableReadFuncTest>DistSyncL1FuncTest.testNoEntryInL1GetWithConcurrentReplace: > {noformat} > 00:23:34,658 ERROR (testng-DistSyncL1RepeatableReadFuncTest:) [UnitTestTestNGListener] Test testNoEntryInL1GetWithConcurrentReplace(org.infinispan.distribution.DistSyncL1RepeatableReadFuncTest) failed. > java.lang.AssertionError: Entry for key [key-to-the-cache] should be in L1 on cache at [NodeA-57647]! > at org.infinispan.distribution.DistributionTestHelper.assertIsInL1(DistributionTestHelper.java:31) > at org.infinispan.distribution.BaseDistFunctionalTest.assertIsInL1(BaseDistFunctionalTest.java:183) > at org.infinispan.distribution.DistSyncL1FuncTest.testNoEntryInL1GetWithConcurrentReplace(DistSyncL1FuncTest.java:193) > {noformat} -- 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

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-3946) Ensure M/R intermediate key/value transfer is chunked properly

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3946?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3946: -------------------------------- Labels: 630 (was: ) > Ensure M/R intermediate key/value transfer is chunked properly > -------------------------------------------------------------- > > Key: ISPN-3946 > URL: https://issues.jboss.org/browse/ISPN-3946 > Project: Infinispan > Issue Type: Bug > Components: Distributed Execution and Map/Reduce > Affects Versions: 6.0.1.Final > Reporter: Vladimir Blagojevic > Assignee: Vladimir Blagojevic > Priority: Minor > Labels: 630 > Fix For: 7.0.0.Alpha1 > > -- 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

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-3951) Make sure TestingUtil.replaceComponent is only called after mock is fully configured

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3951?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3951: -------------------------------- Labels: 630 testsuite_stability (was: testsuite_stability) > Make sure TestingUtil.replaceComponent is only called after mock is fully configured > ------------------------------------------------------------------------------------ > > Key: ISPN-3951 > URL: https://issues.jboss.org/browse/ISPN-3951 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Core > Affects Versions: 6.0.0.Final > Reporter: William Burns > Assignee: William Burns > Labels: 630, testsuite_stability > Fix For: 7.0.0.Alpha1, 7.0.0.Final > > > Some of our tests replace existing components. Unfortunately these could be replaced with mocks that aren't fully initialized until the next line. This can cause spurious test failures. -- 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

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-3913) Infinispan reports incorrect version

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3913?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3913: -------------------------------- Labels: 630 (was: ) > Infinispan reports incorrect version > ------------------------------------ > > Key: ISPN-3913 > URL: https://issues.jboss.org/browse/ISPN-3913 > Project: Infinispan > Issue Type: Bug > Components: Core, Server > Affects Versions: 6.0.1.Final > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Labels: 630 > Fix For: 7.0.0.Alpha1, 7.0.0.Final > > > JmxManagementTest asserts that the Infinispan version string coming from the JMX attribute of a CacheManager contains the word "Infinispan", which is not true. > AbstractSingleNodeMemcachedTest.testStats also asserts the wrong version leading to a failure in MemcachedSingleNodeTest. > There's also another issue, the infinispan core Version.VERSION static field reports 6.0.2-SNAPSHOT and it should actually be 7.0.0-SNAPSHOT. > {quote} > JmxManagementTest.testCacheManagerAttributes (org.infinispan.server.test.jmxmanagement) > > Current failure: #602 rvansa (1) 20 Jan 14 16:17 > First failure: #594 Jakub Markos (1) 09 Jan 14 21:35 > java.lang.AssertionError > at org.junit.Assert.fail(Assert.java:86) > at org.junit.Assert.assertTrue(Assert.java:41) > at org.junit.Assert.assertTrue(Assert.java:52) > at org.infinispan.server.test.jmxmanagement.JmxManagementTest.testCacheManagerAttributes(JmxManagementTest.java:180) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) > at org.jboss.arquillian.junit.Arquillian$6$1.invoke(Arquillian.java:270) > at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60) > at sun.reflect.GeneratedMethodAccessor36.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.execution.ClientTestExecuter.execute(ClientTestExecuter.java:53) > at sun.reflect.GeneratedMethodAccessor35.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createTestContext(ContainerEventController.java:129) > at sun.reflect.GeneratedMethodAccessor34.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75) > at sun.reflect.GeneratedMethodAccessor21.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60) > at sun.reflect.GeneratedMethodAccessor20.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:89) > at sun.reflect.GeneratedMethodAccessor23.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:111) > at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:263) > at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:226) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314) > at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46) > at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:240) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) > at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:185) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314) > at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46) > at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147) > at org.junit.runners.Suite.runChild(Suite.java:127) > at org.junit.runners.Suite.runChild(Suite.java:26) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > at org.junit.runner.JUnitCore.run(JUnitCore.java:160) > at org.junit.runner.JUnitCore.run(JUnitCore.java:138) > at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:62) > at org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:139) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189) > at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165) > at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75) > {quote} -- 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

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-3916) Expiration reaper is not enabled until lifespan or max-idle is set

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3916?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3916: -------------------------------- Assignee: Mircea Markus (was: Wolf-Dieter Fink) > Expiration reaper is not enabled until lifespan or max-idle is set > ------------------------------------------------------------------ > > Key: ISPN-3916 > URL: https://issues.jboss.org/browse/ISPN-3916 > Project: Infinispan > Issue Type: Bug > Components: Server > Affects Versions: 6.0.1.Final > Reporter: Wolf-Dieter Fink > Assignee: Mircea Markus > Labels: 630 > Fix For: 7.0.0.Alpha1, 7.0.0.Final > > > If a cache is added where entities are with and without expiration by external processes it is expected that the reaper purge the data from memory and datastore. > As the reaper is only enabled for the cache if the element > <expiration interval="millis" lifespan="millis" max-idle="millis"/> > has one of the attributes lifespan or max-idle set to a value >0 > The expired entities will not be removed from the memory or datastore. > This is an unexpected behaviour and might end in a memory bottleneck if a server is up for a long time. -- 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

10 years, 1 month

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues March 2014