October 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-2898) Web Cache fails to start when multiple apps are trying to create it

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-2898?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-2898: -------------------------------- Fix Version/s: 6.0.0.Final (was: 6.0.0.CR1) > Web Cache fails to start when multiple apps are trying to create it > ------------------------------------------------------------------- > > Key: ISPN-2898 > URL: https://issues.jboss.org/browse/ISPN-2898 > Project: Infinispan > Issue Type: Bug > Affects Versions: 5.1.7.Final > Reporter: Shay Matasaro > Assignee: Dan Berindei > Fix For: 6.0.0.Final > > > When multiple apps are trying to create/connect to the web cache , the fist one get a lock on the cache manager, and prevents the others from starting it in a timely manner -- 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

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2893) GUI Demo sample configs include old RELAY configuration instead of RELAY2

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-2893?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-2893: -------------------------------- Fix Version/s: 6.0.0.Final (was: 6.0.0.CR1) > GUI Demo sample configs include old RELAY configuration instead of RELAY2 > ------------------------------------------------------------------------- > > Key: ISPN-2893 > URL: https://issues.jboss.org/browse/ISPN-2893 > Project: Infinispan > Issue Type: Feature Request > Components: Demos and Tutorials > Affects Versions: 5.2.3.Final > Reporter: NadirX > Assignee: Mircea Markus > Priority: Minor > Fix For: 6.0.0.Final > > > The files in infinispan/demos/gui/src/main/release/etc/config-samples related to xsite configuration still reference the old RELAY stack instead of the newer RELAY2. -- 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

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2964) putForExternalRead to L1 not invalidated

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-2964?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-2964: -------------------------------- Fix Version/s: 6.0.0.Final (was: 6.0.0.CR1) > putForExternalRead to L1 not invalidated > ---------------------------------------- > > Key: ISPN-2964 > URL: https://issues.jboss.org/browse/ISPN-2964 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache > Affects Versions: 5.2.1.Final > Reporter: Sebastian Tusk > Assignee: William Burns > Fix For: 6.0.0.Final > > Attachments: SebastianTusk_ISPN-2964_fix.patch > > > With transactional distributed caches it happens that Cache.putForExternalRead(k,v) places an entry into L1 that never gets invalidated. It seems to happen when the the owner of k doesn't have the entry. In this case the non owner puts k into his cache without having the owner registering this. Usually the owner stores all requesters in L1ManagerImpl.addRequester and sends out invalidations to the requesters. What should happen is that the entry is replicated to the owner. > Cache config: > <namedCache name="entity"> > <jmxStatistics enabled="true" /> > <clustering mode="dist"> > <stateTransfer fetchInMemoryState="false" timeout="20000" /> > <async /> > <l1 enabled="true" /> > <hash numOwners="1"/> > </clustering> > <locking isolationLevel="READ_COMMITTED" > lockAcquisitionTimeout="15000" useLockStriping="false" /> > <eviction maxEntries="10000" strategy="LRU" /> > <expiration maxIdle="100000" wakeUpInterval="5000"/> > <storeAsBinary storeKeysAsBinary="true" storeValuesAsBinary="false" enabled="false" /> > <transaction transactionMode="TRANSACTIONAL" autoCommit="false" lockingMode="OPTIMISTIC"/> > </namedCache> -- 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

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2958) Lucene Directory Read past EOF

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-2958?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-2958: -------------------------------- Fix Version/s: (was: 6.0.0.CR1) > Lucene Directory Read past EOF > ------------------------------ > > Key: ISPN-2958 > URL: https://issues.jboss.org/browse/ISPN-2958 > Project: Infinispan > Issue Type: Bug > Components: Lucene Directory > Affects Versions: 5.2.1.Final > Reporter: Clement Pang > Assignee: Pedro Ruivo > Labels: retest, stable_embedded_query > Fix For: 6.0.0.Final > > > This seems to be happening rather deterministically. > Infinispan configuration (in JBoss EAP 6.1.0.Alpha): > {code} > <cache-container name="lucene"> > <local-cache name="dshell-index-data" start="EAGER"> > <eviction strategy="LIRS" max-entries="50000"/> > <file-store path="lucene" passivation="true" purge="false"/> > </local-cache> > <local-cache name="dshell-index-metadata" start="EAGER"> > <file-store path="lucene" passivation="true" purge="false"/> > </local-cache> > <local-cache name="dshell-index-lock" start="EAGER"> > <file-store path="lucene" passivation="true" purge="false"/> > </local-cache> > </cache-container> > {code} > Upon shutting down the server and confirming that passivation did indeed write the data to disk, the subsequent start-up would fail right away with: > {code} > Caused by: org.hibernate.search.SearchException: Could not initialize index > at org.hibernate.search.store.impl.DirectoryProviderHelper.initializeIndexIfNeeded(DirectoryProviderHelper.java:162) > at org.hibernate.search.infinispan.impl.InfinispanDirectoryProvider.start(InfinispanDirectoryProvider.java:103) > at org.hibernate.search.indexes.impl.DirectoryBasedIndexManager.initialize(DirectoryBasedIndexManager.java:104) > at org.hibernate.search.indexes.impl.IndexManagerHolder.createIndexManager(IndexManagerHolder.java:227) > ... 64 more > Caused by: java.io.IOException: Read past EOF > at org.infinispan.lucene.SingleChunkIndexInput.readByte(SingleChunkIndexInput.java:77) > at org.apache.lucene.store.ChecksumIndexInput.readByte(ChecksumIndexInput.java:41) > at org.apache.lucene.store.DataInput.readInt(DataInput.java:86) > at org.apache.lucene.index.SegmentInfos.read(SegmentInfos.java:272) > at org.apache.lucene.index.IndexFileDeleter.<init>(IndexFileDeleter.java:182) > at org.apache.lucene.index.IndexWriter.<init>(IndexWriter.java:1168) > at org.hibernate.search.store.impl.DirectoryProviderHelper.initializeIndexIfNeeded(DirectoryProviderHelper.java:157) > ... 67 more > {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

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2938) LuceneCacheLoader to support filtering for preload of the proper type

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-2938?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-2938: -------------------------------- Fix Version/s: 6.0.0.Final (was: 6.0.0.CR1) > LuceneCacheLoader to support filtering for preload of the proper type > --------------------------------------------------------------------- > > Key: ISPN-2938 > URL: https://issues.jboss.org/browse/ISPN-2938 > Project: Infinispan > Issue Type: Feature Request > Components: Lucene Directory > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Labels: stable_embedded_query > Fix For: 6.0.0.Final > > > We suggest to use 3 caches to store the Lucene index, but the design of the LuceneCacheLoader is assuming it is connected to a single cache which need to load all data on preload=true. > We should add options, or perhaps split in different implementations, to only load the relevant part needed for a specifically configured cache. -- 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

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2932) Verify that preloading a read only index in a cache will never hit the cacheloader

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-2932?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-2932: -------------------------------- Fix Version/s: 6.0.0.Final (was: 6.0.0.CR1) > Verify that preloading a read only index in a cache will never hit the cacheloader > ---------------------------------------------------------------------------------- > > Key: ISPN-2932 > URL: https://issues.jboss.org/browse/ISPN-2932 > Project: Infinispan > Issue Type: Task > Components: Lucene Directory > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Fix For: 6.0.0.Final > > > With a warm cache (with no eviction) we should never need to hit the CacheLoader again. > Was reported - specifically with DIST on multiple nodes - that occasionall IO is triggered; we should add tests to verify this doesn't happen (or to understand why it should) > I'm suspecting demand of null valued entries. -- 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

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2990) L1ManagerImpl doesn't reliably invalidate with async caches

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-2990?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-2990: -------------------------------- Fix Version/s: 6.0.0.Final (was: 6.0.0.CR1) > L1ManagerImpl doesn't reliably invalidate with async caches > ----------------------------------------------------------- > > Key: ISPN-2990 > URL: https://issues.jboss.org/browse/ISPN-2990 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache > Affects Versions: 5.2.1.Final > Reporter: Sebastian Tusk > Assignee: William Burns > Priority: Minor > Labels: onboard > Fix For: 6.0.0.Final > > > B is owner of k,v1 > A has k,v1 in L1 > 1. TX: A puts k,v2 > 2. TX: A sends async PrepareCommand k,v2 to B (one-phase-commit) > 3. TX: A removes k,v1 from L1 > 4. A putForExternalRead k,v1 and has it in L1 again > 5. TX: B executes PrepareCommand k,v2 but doesn't send invalidation to origin > Result: A has k,v1 and B has k,v2 > Solution: For async caches send invalidation to origin too. > The problem is that the owner updates the cache entry asynchronously. This gives the origin of the transaction time to request the entry. Here an outdated version is received and placed in L1. The owner never invalidates the entry and as result the cache is inconsistent. -- 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

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2979) Distributed executor doesn't failover tasks if the user didn't call future.get()

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-2979?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-2979: -------------------------------- Fix Version/s: 6.0.0.Final (was: 6.0.0.CR1) > Distributed executor doesn't failover tasks if the user didn't call future.get() > -------------------------------------------------------------------------------- > > Key: ISPN-2979 > URL: https://issues.jboss.org/browse/ISPN-2979 > Project: Infinispan > Issue Type: Bug > Components: Distributed Execution and Map/Reduce > Affects Versions: 5.2.0.Final > Reporter: Dan Berindei > Assignee: Vladimir Blagojevic > Fix For: 6.0.0.Final > > > Failover only happens during DistributedTaskPart.innerGet(), so the task will not re-run on other nodes if it failed but the user never called future.get(). -- 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

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2971) AsyncStoreStressTest is broken

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-2971?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-2971: -------------------------------- Fix Version/s: 6.0.0.Final (was: 6.0.0.CR1) > AsyncStoreStressTest is broken > ------------------------------ > > Key: ISPN-2971 > URL: https://issues.jboss.org/browse/ISPN-2971 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 5.2.5.Final > Reporter: Adrian Nistor > Assignee: Galder Zamarreño > Priority: Minor > Labels: testsuite_stability > Fix For: 6.0.0.Final > > > This test is not run during normal test suite, but we still need to fix this failure and the leaked threads (see System.exit(0) in main method): > {code} > testReadWriteRemove(org.infinispan.stress.AsyncStoreStressTest) Time elapsed: 72.377 sec <<< FAILURE! > java.lang.UnsupportedOperationException > at java.util.AbstractMap$SimpleImmutableEntry.setValue(AbstractMap.java:726) > at org.infinispan.stress.AsyncStoreStressTest.testReadWriteRemove(AsyncStoreStressTest.java:140) > 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.Invoker.invokeMethod(Invoker.java:714) > at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901) > at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231) > at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127) > at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111) > at org.testng.TestRunner.privateRun(TestRunner.java:767) > at org.testng.TestRunner.run(TestRunner.java:617) > at org.testng.SuiteRunner.runTest(SuiteRunner.java:334) > at org.testng.SuiteRunner.access$000(SuiteRunner.java:37) > at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:368) > at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64) > 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:895) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) > at java.lang.Thread.run(Thread.java:662) > {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

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3003) Version 5.2.5.Final of infinispan-cdi test dependencies

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3003?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-3003: -------------------------------- Fix Version/s: 6.0.0.Final (was: 6.0.0.CR1) > Version 5.2.5.Final of infinispan-cdi test dependencies > ------------------------------------------------------- > > Key: ISPN-3003 > URL: https://issues.jboss.org/browse/ISPN-3003 > Project: Infinispan > Issue Type: Bug > Components: CDI integration > Affects Versions: 5.2.5.Final > Reporter: Gregor Kovač > Assignee: Tristan Tarrant > Fix For: 6.0.0.Final > > Attachments: TestInfinispan.zip > > > infinispan-cdi has a test dependency on infinispan-server-core: > <dependency> > <groupId>${project.groupId}</groupId> > <artifactId>infinispan-server-core</artifactId> > <type>test-jar</type> > </dependency> > which is wrong since it is missing the <scope>test</scope>, so every time I want to use infinispan-cdi in my projects I get: > Failed to initialize ear modules: Unknown artifact type[test-jar] -- 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

12 years, 6 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 October 2013