October 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-3354) Multiple events on the local node with Infinispan 5.3.0-final

by Divya Mehra (JIRA)

[ https://issues.jboss.org/browse/ISPN-3354?page=com.atlassian.jira.plugin.... ] Divya Mehra updated ISPN-3354: ------------------------------ Labels: jdg620_dm (was: ) > Multiple events on the local node with Infinispan 5.3.0-final > ------------------------------------------------------------- > > Key: ISPN-3354 > URL: https://issues.jboss.org/browse/ISPN-3354 > Project: Infinispan > Issue Type: Bug > Components: Listeners > Affects Versions: 5.3.0.Final > Reporter: Luca Zenti > Assignee: Mircea Markus > Labels: jdg620_dm > Attachments: TestInfinispanDuplicatedEvents.java > > > After upgrading to Infinispan 5.3.0-final I found a strange "intermittent" problem in my application. Digging a bit deeper, I found out it is due to CacheEntry events raised twice for some keys on the local node (the node where the cache operation is invoked). > I was able to reproduce the problem and I wrote the attached test case. > The problem happens regardless of the cluster mode, but only with non-transactional caches. I think this is due to the fact that with transactional caches the events are raised on commit. > Also, my application used to work with an interceptor rather than an event listener, so I actually found the problem when I saw my interceptor being occasionally executed 3 times with 2 nodes. > I'm not sure whether the command and the chain of interceptor is really meant to be executed twice on the local node, but the consequent behaviour on the events sounds like a bug. -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3432) Data put to index enabled cache with Infinispan Directory provider using Async. JDBC StringBased CacheStore fails

by Divya Mehra (JIRA)

[ https://issues.jboss.org/browse/ISPN-3432?page=com.atlassian.jira.plugin.... ] Divya Mehra updated ISPN-3432: ------------------------------ Labels: jdg620_dm (was: ) > Data put to index enabled cache with Infinispan Directory provider using Async. JDBC StringBased CacheStore fails > ----------------------------------------------------------------------------------------------------------------- > > Key: ISPN-3432 > URL: https://issues.jboss.org/browse/ISPN-3432 > Project: Infinispan > Issue Type: Bug > Components: Querying > Affects Versions: 6.0.0.Alpha1 > Reporter: Anna Manukyan > Assignee: Sanne Grinovero > Labels: jdg620_dm > Attachments: async-config.xml > > > Hi, > this issue is related to the ISPN-3090, but I thought to specify this case separately for bringing detailed explanation for the configuration and thrown exceptions. > The issue relates to the performance tests for Index enabled Infinispan cache, with configured Infinispan directory and Async JDBC. String Based Cache store. > The tests are running on 4 nodes and performing puts/gets on all nodes with many threads. > The problem is that, during data put, the following exceptions are thrown continuously: > {code} > 04:04:05,633 ERROR [org.hibernate.search.exception.impl.LogErrorHandler] (Hibernate Search: Index updates queue processor for index query-1) HSEARCH000058: Exception occurred org.apache.lucene.index.IndexNotFoundException: no segments* file found in InfinispanDirectory{indexName='query'}: files: [] > Primary Failure: > Entity org.radargun.cachewrappers.InfinispanQueryWrapper$QueryableData Id S:_InstallBenchmarkStage_0 Work Type org.hibernate.search.backend.UpdateLuceneWork > org.apache.lucene.index.IndexNotFoundException: no segments* file found in InfinispanDirectory{indexName='query'}: files: [] > at org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:667) > at org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:554) > at org.apache.lucene.index.SegmentInfos.read(SegmentInfos.java:359) > at org.apache.lucene.index.IndexWriter.<init>(IndexWriter.java:1138) > at org.hibernate.search.backend.impl.lucene.IndexWriterHolder.createNewIndexWriter(IndexWriterHolder.java:148) > at org.hibernate.search.backend.impl.lucene.IndexWriterHolder.getIndexWriter(IndexWriterHolder.java:115) > at org.hibernate.search.backend.impl.lucene.AbstractWorkspaceImpl.getIndexWriter(AbstractWorkspaceImpl.java:117) > at org.hibernate.search.backend.impl.lucene.LuceneBackendQueueTask.applyUpdates(LuceneBackendQueueTask.java:101) > at org.hibernate.search.backend.impl.lucene.LuceneBackendQueueTask.run(LuceneBackendQueueTask.java:67) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) > at java.util.concurrent.FutureTask.run(FutureTask.java:166) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:724) > ...... > 04:14:21,605 ERROR [org.hibernate.search.exception.impl.LogErrorHandler] (Hibernate Search: Index updates queue processor for index query-1) HSEARCH000058: Exception occurred org.apache.lucene.index.IndexNotFoundException: no segments* file found in InfinispanDirectory{indexName='query'}: files: [] > Primary Failure: > Entity org.radargun.cachewrappers.InfinispanQueryWrapper$QueryableData Id S:key_0_0_0000000000000017 Work Type org.hibernate.search.backend.UpdateLuceneWork > org.apache.lucene.index.IndexNotFoundException: no segments* file found in InfinispanDirectory{indexName='query'}: files: [] > at org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:667) > at org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:554) > at org.apache.lucene.index.SegmentInfos.read(SegmentInfos.java:359) > at org.apache.lucene.index.IndexWriter.<init>(IndexWriter.java:1138) > at org.hibernate.search.backend.impl.lucene.IndexWriterHolder.createNewIndexWriter(IndexWriterHolder.java:148) > at org.hibernate.search.backend.impl.lucene.IndexWriterHolder.getIndexWriter(IndexWriterHolder.java:115) > at org.hibernate.search.backend.impl.lucene.AbstractWorkspaceImpl.getIndexWriter(AbstractWorkspaceImpl.java:117) > at org.hibernate.search.backend.impl.lucene.LuceneBackendQueueTask.applyUpdates(LuceneBackendQueueTask.java:101) > at org.hibernate.search.backend.impl.lucene.LuceneBackendQueueTask.run(LuceneBackendQueueTask.java:67) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) > at java.util.concurrent.FutureTask.run(FutureTask.java:166) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:724) > {code} > You can find the cache configuration attached. > Yet another thing to mention: > if the following line is added to the cache configuration: > {code} > <property name="default.indexmanager" value="org.infinispan.query.indexmanager.InfinispanIndexManager" /> > {code} > then the issue is gone - no lock issue appears then. -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3426) L1 inconsistency in tx caches when backup owner replies to remote get

by Divya Mehra (JIRA)

[ https://issues.jboss.org/browse/ISPN-3426?page=com.atlassian.jira.plugin.... ] Divya Mehra updated ISPN-3426: ------------------------------ Labels: jdg620_dm (was: ) > L1 inconsistency in tx caches when backup owner replies to remote get > --------------------------------------------------------------------- > > Key: ISPN-3426 > URL: https://issues.jboss.org/browse/ISPN-3426 > Project: Infinispan > Issue Type: Bug > Affects Versions: 6.0.0.Alpha2 > Reporter: Pedro Ruivo > Assignee: William Burns > Labels: jdg620_dm > > Consider the following scenario > {noformat}node1: performs a remote get > node2 (backup owner): receives and replies to the remote get with v1 > node1: receives the repli and store in L1_ key => v1 > node2 (backup owner): commits a new value (v2) for the key (i.e. processes a commit command) > node3 (primary owner): sends the invalidation (but not for node1 because it hasn't received the remote get yet) and commits a new value (v2) for the key (i.e. processes a commit command) > node3 (primary owner): replies to the remote get with v2 > node1: ignores the reply because it used the node2 reply > {noformat} > *conclustion*: node1 keeps the old value stored in L1. > Possible solutions described here: > [L1 consistency for transactional caches|http://markmail.org/thread/ckbihuj5ch7qtdzj] > Could also be interesting: > [Staggered get question|http://markmail.org/thread/qun2frj2u5a2hnj2] > and > [ISPN-825|https://issues.jboss.org/browse/ISPN-825] -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3396) Multiple classloader key store/lookup fails, even with storeAsBinary

by Divya Mehra (JIRA)

[ https://issues.jboss.org/browse/ISPN-3396?page=com.atlassian.jira.plugin.... ] Divya Mehra updated ISPN-3396: ------------------------------ Labels: jdg620_dm (was: ) > Multiple classloader key store/lookup fails, even with storeAsBinary > -------------------------------------------------------------------- > > Key: ISPN-3396 > URL: https://issues.jboss.org/browse/ISPN-3396 > Project: Infinispan > Issue Type: Bug > Components: Marshalling > Affects Versions: 5.3.0.Final, 6.0.0.Alpha2 > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Labels: jdg620_dm > > Same key, multiple classloaders. Storing from one classloader cannot be found from the other, even when storeAsBinary is enabled (even with defensive=true). [IRC chat debugging issue|https://gist.github.com/galderz/63163644fee0c27d66c7]. -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3462) Unable to add custom interceptors declaratively to server config

by Divya Mehra (JIRA)

[ https://issues.jboss.org/browse/ISPN-3462?page=com.atlassian.jira.plugin.... ] Divya Mehra updated ISPN-3462: ------------------------------ Labels: jdg620_dm (was: ) > Unable to add custom interceptors declaratively to server config > ---------------------------------------------------------------- > > Key: ISPN-3462 > URL: https://issues.jboss.org/browse/ISPN-3462 > Project: Infinispan > Issue Type: Bug > Components: Server > Affects Versions: 5.3.0.Final > Reporter: Riad Mohammed > Assignee: Tristan Tarrant > Labels: jdg620_dm > > Per Tristan Tarrant, creating jira ticket: > I've upgraded from Infinispan 5.2.5 to Infinispan server 5.3 and it looks like the configuration file (urn:infinispan:server:core:5.3) doesn't support declaring custom interceptors as jboss-infinispan-core_5_3.xsd does not have the necessary elements. [I did try just adding the custom interceptor elements and got a parse error]. -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3468) ClassCastException in map-reduce with unfamiliar key type, some cache stores and storeAsBinary

by Divya Mehra (JIRA)

[ https://issues.jboss.org/browse/ISPN-3468?page=com.atlassian.jira.plugin.... ] Divya Mehra updated ISPN-3468: ------------------------------ Labels: jdg62_dm (was: ) > ClassCastException in map-reduce with unfamiliar key type, some cache stores and storeAsBinary > ---------------------------------------------------------------------------------------------- > > Key: ISPN-3468 > URL: https://issues.jboss.org/browse/ISPN-3468 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 5.3.0.Final > Reporter: Krzysztof Sobolewski > Assignee: Mircea Markus > Labels: jdg62_dm > Attachments: 0001-core-add-BaseCacheStoreFunctionalTest.testMapReduceS.patch > > > The conditions needed to replicate: > 1) storeAsBinary enabled for keys > 2) a cache store that marshals keys directly, e.g. any BucketBasedCacheStore (I'm using JdbcBinaryCacheStore) > 3) a key type that is unfamiliar to MarshalledValue.isTypeExcluded(Class<?>) > If these are satisfied, then map-reduce fails with an exception like this: > org.infinispan.CacheException: java.util.concurrent.ExecutionException: java.lang.ClassCastException: org.infinispan.marshall.MarshalledValue cannot be cast to com.example.UnfamiliarKeyType > at com.example.TestMapper.map(TestMapper.java:11) ~[?:?] > at org.infinispan.distexec.mapreduce.MapReduceManagerImpl.map(MapReduceManagerImpl.java:216) ~[?:?] > at org.infinispan.distexec.mapreduce.MapReduceManagerImpl.mapAndCombineForLocalReduction(MapReduceManagerImpl.java:103) ~[?:?] > at org.infinispan.distexec.mapreduce.MapReduceTask$MapTaskPart.invokeMapCombineLocallyForLocalReduction(MapReduceTask.java:977) ~[?:?] > at org.infinispan.distexec.mapreduce.MapReduceTask$MapTaskPart.access$300(MapReduceTask.java:916) ~[?:?] > at org.infinispan.distexec.mapreduce.MapReduceTask$MapTaskPart$2.call(MapReduceTask.java:948) ~[?:?] > at org.infinispan.distexec.mapreduce.MapReduceTask$MapTaskPart$2.call(MapReduceTask.java:944) ~[?:?] > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) ~[?:1.6.0_45] > at java.util.concurrent.FutureTask.run(FutureTask.java:138) ~[?:1.6.0_45] > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439) ~[?:1.6.0_45] > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) ~[?:1.6.0_45] > at java.util.concurrent.FutureTask.run(FutureTask.java:138) ~[?:1.6.0_45] > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) ~[?:1.6.0_45] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) ~[?:1.6.0_45] -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3531) LifecycleManager of query module keeps references to per cache manager resources (jmx related)

by Divya Mehra (JIRA)

[ https://issues.jboss.org/browse/ISPN-3531?page=com.atlassian.jira.plugin.... ] Divya Mehra updated ISPN-3531: ------------------------------ Labels: jdg620_dm (was: ) > LifecycleManager of query module keeps references to per cache manager resources (jmx related) > ---------------------------------------------------------------------------------------------- > > Key: ISPN-3531 > URL: https://issues.jboss.org/browse/ISPN-3531 > Project: Infinispan > Issue Type: Bug > Components: Querying > Affects Versions: 6.0.0.Alpha4 > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Priority: Minor > Labels: jdg620_dm > > The resources in question are gathered when a cache manager is started and are used again when it is stopped. This does not work well if there are multiple cache managers that have different jmx domains. > Cache stop event also does not seem to be processed correctly. -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3558) PutForExternalRead won't work after a clear(), when both in same tx

by Divya Mehra (JIRA)

[ https://issues.jboss.org/browse/ISPN-3558?page=com.atlassian.jira.plugin.... ] Divya Mehra updated ISPN-3558: ------------------------------ Labels: jdg620_dm (was: ) > PutForExternalRead won't work after a clear(), when both in same tx > ------------------------------------------------------------------- > > Key: ISPN-3558 > URL: https://issues.jboss.org/browse/ISPN-3558 > Project: Infinispan > Issue Type: Bug > Components: Transactions > Affects Versions: 5.3.0.Final, 6.0.0.Beta1 > Reporter: Galder Zamarreño > Assignee: William Burns > Priority: Blocker > Labels: jdg620_dm > Fix For: 6.0.0.Final > > > {code} > public void testPutForExternalReadAfterClear() throws Exception { > cache.put(1, "v1"); > tm().begin(); > try { > cache.getAdvancedCache().clear(); > cache.putForExternalRead(1, "v1"); > assertEquals("v1", cache.get(1)); > } finally { > tm().commit(); > } > } > {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

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3602) Cache statistics update differently in library and Client-Server mode

by Divya Mehra (JIRA)

[ https://issues.jboss.org/browse/ISPN-3602?page=com.atlassian.jira.plugin.... ] Divya Mehra updated ISPN-3602: ------------------------------ Labels: jdg620_dm (was: ) > Cache statistics update differently in library and Client-Server mode > --------------------------------------------------------------------- > > Key: ISPN-3602 > URL: https://issues.jboss.org/browse/ISPN-3602 > Project: Infinispan > Issue Type: Bug > Components: Core API > Affects Versions: 6.0.0.CR1 > Reporter: Jiří Holuša > Assignee: Mircea Markus > Priority: Minor > Labels: jdg620_dm > > When running jdg quickstart carmart ( https://github.com/infinispan/jdg-quickstart/tree/master/carmart ) I noticed interesting thing. > When calling replace() in library mode, the number of stores in cache statistics doesn't change whereas when calling in Client-Server mode, the number of stores increase by 1. > I went deeper into the code and I found out that in CacheMgmtInterceptor, where there are implemented methods for such statistics updates (like for put() ), there isn't implemented method for updating stats for replace() method, so the control flow is just passed. > I think it should be consistent, but I don't know which approach is intended, if either increase by 1 or leave it the same. > If increase is the answer than the solution is simple, implement CacheMgmtInterceptor.visitReplaceCommand(...) the same way as e.g. visitPutKeyValueCommand. -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3589) StackOverflow in InternalMetadataImpl.Externalizer

by Divya Mehra (JIRA)

[ https://issues.jboss.org/browse/ISPN-3589?page=com.atlassian.jira.plugin.... ] Divya Mehra updated ISPN-3589: ------------------------------ Labels: jdg620_dm (was: ) > StackOverflow in InternalMetadataImpl.Externalizer > -------------------------------------------------- > > Key: ISPN-3589 > URL: https://issues.jboss.org/browse/ISPN-3589 > Project: Infinispan > Issue Type: Bug > Affects Versions: 6.0.0.CR1 > Reporter: Pedro Ruivo > Assignee: Mircea Markus > Labels: jdg620_dm > > the implementation delegates to another metadata some methods. The result is a chain of InternalMetadataImpl as you can see in: > {code} > metadata=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=Inte > rnalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl > {actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=Internal > MetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{act > ual=InternalMetadataImpl [....] > {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

10 years, 6 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues October 2013