[JBoss JIRA] (ISPN-3287) Possible inconsistency with concurrent transactions during state transfer
by Divya Mehra (JIRA)
[ https://issues.jboss.org/browse/ISPN-3287?page=com.atlassian.jira.plugin.... ]
Divya Mehra updated ISPN-3287:
------------------------------
Labels: jdg620_dm jdg62GAblocker (was: jdg620_dm)
> Possible inconsistency with concurrent transactions during state transfer
> -------------------------------------------------------------------------
>
> Key: ISPN-3287
> URL: https://issues.jboss.org/browse/ISPN-3287
> Project: Infinispan
> Issue Type: Bug
> Components: Locking and Concurrency, State transfer
> Affects Versions: 5.3.0.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Labels: jdg620_dm, jdg62GAblocker
>
> It looks like there is a data race between the state transfer thread and a concurrent transaction in EntryWrappingInterceptor.commitEntryIfNeeded:
> tx: commitContextEntry()
> ST: stateConsumer.isKeyUpdated(k)? false
> tx: stateConsumer.addUpdatedKey(k)
> ST: commitContextEntry()
> We probably need some synchronization here, maybe using EquivalentConcurrentHashMapV8.computeIfAbsent().
--
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, 5 months
[JBoss JIRA] (ISPN-3335) JMX statistics for Queries partially doesn't work
by Divya Mehra (JIRA)
[ https://issues.jboss.org/browse/ISPN-3335?page=com.atlassian.jira.plugin.... ]
Divya Mehra updated ISPN-3335:
------------------------------
Labels: jdg620_dm jdg62GAblocker (was: jdg620_dm)
> JMX statistics for Queries partially doesn't work
> -------------------------------------------------
>
> Key: ISPN-3335
> URL: https://issues.jboss.org/browse/ISPN-3335
> Project: Infinispan
> Issue Type: Bug
> Components: Querying
> Affects Versions: 6.0.0.Alpha1
> Reporter: Anna Manukyan
> Assignee: Sanne Grinovero
> Labels: jdg620_dm, jdg62GAblocker
> Attachments: QueryMBeanTest.java
>
>
> I was playing around with Query JMX statistics, and found out that there are several attributes like SearchQueryTotalTime are always 0 (this attr. represents the duration of query in nano-seconds), even though I'm running the infinispan query.
> The only attribute which is updated and returns proper value is StatisticsEnabled. Also the following operations work as expected:
> getNumberOfIndexedEntities(String entity)
> clear()
> I've tried also to retrieve the statistics using the following method:
> {code}
> Search.getSearchManager(cacheManager.getCache(CACHE_NAME)).getSearchFactory().getStatistics().getSearchQueryTotalTime()
> {code}
> and it returns the same results as if getting via JMX.
> You can find the whole running test attached.
> Best regards,
> Anna.
--
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, 5 months
[JBoss JIRA] (ISPN-3316) CDI Cache interceptor tests are failing while running in EAP container
by Divya Mehra (JIRA)
[ https://issues.jboss.org/browse/ISPN-3316?page=com.atlassian.jira.plugin.... ]
Divya Mehra updated ISPN-3316:
------------------------------
Labels: jdg620_dm jdg62GAblocker (was: jdg620_dm)
> CDI Cache interceptor tests are failing while running in EAP container
> ----------------------------------------------------------------------
>
> Key: ISPN-3316
> URL: https://issues.jboss.org/browse/ISPN-3316
> Project: Infinispan
> Issue Type: Bug
> Components: CDI integration
> Affects Versions: 5.3.0.Final
> Reporter: Anna Manukyan
> Assignee: Mircea Markus
> Labels: jdg620_dm, jdg62GAblocker
>
> While migration of the CDI related tests to work under EAP container (at the moment using 6.0.GA), it was found that the tests related to interceptors are failing. The issue relates to
> org.infinispan.cdi.test.interceptor.CachePutInterceptorTest, org.infinispan.cdi.test.interceptor.CacheRemoveAllInterceptorTest, org.infinispan.cdi.test.interceptor.CacheRemoveInterceptorTest, org.infinispan.cdi.test.interceptor.CacheResultInterceptorTest.
> The failure relates to assertions. The thing is that all actions which are done using javax.cache.cache-api annotations, work properly (I've added some logs e.g. in CachePutInterceptor, and it shows that the data is put to the cache properly).
> But later when the test wants to verify that the data is really put to the data, retrieves the cache from the injected CacheContainer, the cache is empty - the data is not there.
> The issue appeared since the latest changes to the Infinispan-CDI module, and split to infinispan-jcache module. For the previous version, the tests are passed under EAP container.
> The example above was given for the CachePutInterceptorTest, but the same refers to the rest of them.
> The git repo for the sources, will be provided later.
--
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, 5 months
[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 jdg62GAblocker (was: jdg620_dm)
> 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, jdg62GAblocker
> 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, 5 months
[JBoss JIRA] (ISPN-3407) Entry passivation doesn't work according to eviction strategy
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3407?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3407:
--------------------------------
Affects Version/s: 5.3.0.Final
(was: 6.0.0.Alpha2)
> Entry passivation doesn't work according to eviction strategy
> -------------------------------------------------------------
>
> Key: ISPN-3407
> URL: https://issues.jboss.org/browse/ISPN-3407
> Project: Infinispan
> Issue Type: Bug
> Components: Eviction
> Affects Versions: 5.3.0.Final
> Reporter: Vitalii Chepeliuk
> Assignee: Mircea Markus
> Labels: jdg620_dm
>
> {code:title=Test.java|borderStyle=solid}
> GlobalConfiguration globalConf = new GlobalConfigurationBuilder().nonClusteredDefault().build();
> ConfigurationBuilder builder = new ConfigurationBuilder();
> builder.clustering().cacheMode(CacheMode.LOCAL)
> .loaders().passivation(true).preload(false).shared(false)
> .addLoader(JdbcStringBasedCacheStoreConfigurationBuilder.class).fetchPersistentState(false).purgeOnStartup(false)
> .table()
> .databaseType(DatabaseType.MYSQL)
> .dropOnExit(false)
> .createOnStart(true)
> .tableNamePrefix("ISPN6Alpha2_STRING")
> .idColumnName("ID").idColumnType("VARCHAR(255)")
> .dataColumnName("DATA").dataColumnType("VARBINARY(1000)")
> .timestampColumnName("TIMESTAMP").timestampColumnType("BIGINT")
> .connectionPool()
> .connectionUrl()
> .username("username")
> .password("password")
> .driverClass("com.mysql.jdbc.Driver")
> .eviction().strategy(EvictionStrategy.LRU).maxEntries(2);
> Configuration localConf = builder.build();
> DefaultCacheManager defCacheManager = new DefaultCacheManager(globalConf, localConf, true);
> Cache<String, String> cache = defCacheManager.getCache();
> cache.put("k1", "v1");
> cache.put("k2", "v2");
> //not yet in store (eviction.max-entries=2, LRU)
> cache.put("k3", "v3");
> assertEquals("v3", cache.get("k3"));
> //now k1 evicted and stored in store
> assertEquals(2, cache.size()); <<< only 2 entries should remain in cache, k1 should be passivated and removed. But doesn't work!
> {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, 5 months
[JBoss JIRA] (ISPN-3407) Entry passivation doesn't work according to eviction strategy
by Divya Mehra (JIRA)
[ https://issues.jboss.org/browse/ISPN-3407?page=com.atlassian.jira.plugin.... ]
Divya Mehra updated ISPN-3407:
------------------------------
Labels: jdg620_dm jdg62GAblocker (was: jdg620_dm)
> Entry passivation doesn't work according to eviction strategy
> -------------------------------------------------------------
>
> Key: ISPN-3407
> URL: https://issues.jboss.org/browse/ISPN-3407
> Project: Infinispan
> Issue Type: Bug
> Components: Eviction
> Affects Versions: 5.3.0.Final
> Reporter: Vitalii Chepeliuk
> Assignee: Mircea Markus
> Labels: jdg620_dm, jdg62GAblocker
>
> {code:title=Test.java|borderStyle=solid}
> GlobalConfiguration globalConf = new GlobalConfigurationBuilder().nonClusteredDefault().build();
> ConfigurationBuilder builder = new ConfigurationBuilder();
> builder.clustering().cacheMode(CacheMode.LOCAL)
> .loaders().passivation(true).preload(false).shared(false)
> .addLoader(JdbcStringBasedCacheStoreConfigurationBuilder.class).fetchPersistentState(false).purgeOnStartup(false)
> .table()
> .databaseType(DatabaseType.MYSQL)
> .dropOnExit(false)
> .createOnStart(true)
> .tableNamePrefix("ISPN6Alpha2_STRING")
> .idColumnName("ID").idColumnType("VARCHAR(255)")
> .dataColumnName("DATA").dataColumnType("VARBINARY(1000)")
> .timestampColumnName("TIMESTAMP").timestampColumnType("BIGINT")
> .connectionPool()
> .connectionUrl()
> .username("username")
> .password("password")
> .driverClass("com.mysql.jdbc.Driver")
> .eviction().strategy(EvictionStrategy.LRU).maxEntries(2);
> Configuration localConf = builder.build();
> DefaultCacheManager defCacheManager = new DefaultCacheManager(globalConf, localConf, true);
> Cache<String, String> cache = defCacheManager.getCache();
> cache.put("k1", "v1");
> cache.put("k2", "v2");
> //not yet in store (eviction.max-entries=2, LRU)
> cache.put("k3", "v3");
> assertEquals("v3", cache.get("k3"));
> //now k1 evicted and stored in store
> assertEquals(2, cache.size()); <<< only 2 entries should remain in cache, k1 should be passivated and removed. But doesn't work!
> {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, 5 months
[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 jdg62GAblocker (was: jdg620_dm)
> 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, jdg62GAblocker
> 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, 5 months