[JBoss JIRA] (ISPN-9136) RegionFactory.stop does not undefine pending-puts cache
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-9136?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-9136:
----------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> RegionFactory.stop does not undefine pending-puts cache
> -------------------------------------------------------
>
> Key: ISPN-9136
> URL: https://issues.jboss.org/browse/ISPN-9136
> Project: Infinispan
> Issue Type: Bug
> Components: Hibernate Cache
> Affects Versions: 9.2.2.Final, 9.3.0.Alpha1
> Reporter: Radim Vansa
> Assignee: Radim Vansa
> Fix For: 9.3.0.Beta1, 9.2.3.Final
>
>
> When shutting down the RegionFactory the caches belonging to regions are cleaned up; pending-puts caches are not, though.
> Actually this is not really a problem since SessionFactoryImp.close > EnabledCaching.close iterates through all regions and calls 'destroy'. However we should centralize the shutdown a bit and make the impl more resilient against starting with existing configuration.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 5 months
[JBoss JIRA] (ISPN-9136) RegionFactory.stop does not undefine pending-puts cache
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-9136?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-9136:
----------------------------------
Fix Version/s: 9.2.3.Final
> RegionFactory.stop does not undefine pending-puts cache
> -------------------------------------------------------
>
> Key: ISPN-9136
> URL: https://issues.jboss.org/browse/ISPN-9136
> Project: Infinispan
> Issue Type: Bug
> Components: Hibernate Cache
> Affects Versions: 9.2.2.Final, 9.3.0.Alpha1
> Reporter: Radim Vansa
> Assignee: Radim Vansa
> Fix For: 9.2.3.Final
>
>
> When shutting down the RegionFactory the caches belonging to regions are cleaned up; pending-puts caches are not, though.
> Actually this is not really a problem since SessionFactoryImp.close > EnabledCaching.close iterates through all regions and calls 'destroy'. However we should centralize the shutdown a bit and make the impl more resilient against starting with existing configuration.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 5 months
[JBoss JIRA] (ISPN-9125) 2LC memory leak on delete
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-9125?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-9125:
----------------------------------
Fix Version/s: 9.2.3.Final
> 2LC memory leak on delete
> -------------------------
>
> Key: ISPN-9125
> URL: https://issues.jboss.org/browse/ISPN-9125
> Project: Infinispan
> Issue Type: Bug
> Components: Hibernate Cache
> Affects Versions: 9.2.2.Final, 9.3.0.Alpha1
> Reporter: Radim Vansa
> Assignee: Radim Vansa
> Fix For: 9.3.0.Beta1, 9.2.3.Final
>
>
> When applications deletes an entity, a {{PendingPut}} is added to the pending put map as if we should put-from-load the updated value after the transaction completes. Since the value is null, we do not remove the pending put afterwards, though.
> The record is eventually garbage-collected based on timestamp but until then the garbage collection has performance impact if we delete the same entry many times.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 5 months
[JBoss JIRA] (ISPN-375) Enable Hot Rod clients to start transactions
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/ISPN-375?page=com.atlassian.jira.plugin.s... ]
Radoslav Husar updated ISPN-375:
--------------------------------
Priority: Critical (was: Blocker)
> Enable Hot Rod clients to start transactions
> --------------------------------------------
>
> Key: ISPN-375
> URL: https://issues.jboss.org/browse/ISPN-375
> Project: Infinispan
> Issue Type: Feature Request
> Components: Remote Protocols
> Reporter: Galder Zamarreño
> Assignee: Pedro Ruivo
> Priority: Critical
> Fix For: 9.3.0.Final
>
>
> It might be useful to allow Hot Rod clients to start transactions within Hot Rod servers. The possibility of clients participating in the actual transaction, i.e. being an XAResource, should not be imposed since this might be less than trivial to achieve in non-Java environments. The alternative would be to allow clients to start Hot Rod server local transactions only.
> This would require enhancing Hot Rod spec to have some begin/commit/rollback commands that return a tx id, and for clients to be able to send this id as part of each command that should participate in the transaction.
> Pitfalls to avoid include avoiding a transaction to be propagated over several Hot Rod servers. IOW, to simplify things, if a tx is started in server A, all ops within that tx should be directed to tx. Load balancing could still happen but would need to be tx sticky.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 5 months
[JBoss JIRA] (ISPN-7807) Hot Rod Lightweight Transaction (Synchronization)
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/ISPN-7807?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated ISPN-7807:
---------------------------------
Description: A JIRA to track future JIRAs related to hot rod transactions (synchronization only, another JIRA will be created for full XA). (was: A JIRA to track future JIRAs related to hot rod transactions. (Syncrhonization only, another JIRA will be created for full XA))
> Hot Rod Lightweight Transaction (Synchronization)
> -------------------------------------------------
>
> Key: ISPN-7807
> URL: https://issues.jboss.org/browse/ISPN-7807
> Project: Infinispan
> Issue Type: Feature Request
> Components: Remote Protocols, Transactions
> Reporter: Pedro Ruivo
> Assignee: Pedro Ruivo
>
> A JIRA to track future JIRAs related to hot rod transactions (synchronization only, another JIRA will be created for full XA).
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 5 months
[JBoss JIRA] (ISPN-8160) ClusteredCacheWithAffinityIndexManagerTxTest random failures with trace logging enabled
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-8160?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes commented on ISPN-8160:
-----------------------------------------
Let me send a PR for https://issues.jboss.org/browse/ISPN-8799 and we shall see if the timeouts are gone
> ClusteredCacheWithAffinityIndexManagerTxTest random failures with trace logging enabled
> ---------------------------------------------------------------------------------------
>
> Key: ISPN-8160
> URL: https://issues.jboss.org/browse/ISPN-8160
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Query
> Affects Versions: 9.1.0.Final
> Reporter: Dan Berindei
> Assignee: Gustavo Fernandes
> Priority: Critical
> Labels: testsuite_stability
>
> The test usually passes when run by itself, but when run in parallel with other tests often getting one or more failures. The failing test method is not always the same, e.g.
> {noformat}
> 13:10:28,264 ERROR (testng-Test:[]) [TestSuiteProgress] Test failed: org.infinispan.query.blackbox.ClusteredCacheWithAffinityIndexManagerTxTest.testCompute
> org.hibernate.search.exception.SearchException: Unable to reopen IndexReader
> at org.hibernate.search.indexes.impl.SharingBufferReaderProvider$PerDirectoryLatestReader.refreshAndGet(SharingBufferReaderProvider.java:242) ~[hibernate-search-engine-5.8.0.Beta4.jar:5.8.0.Beta4]
> at org.hibernate.search.indexes.impl.SharingBufferReaderProvider.openIndexReader(SharingBufferReaderProvider.java:73) ~[hibernate-search-engine-5.8.0.Beta4.jar:5.8.0.Beta4]
> at org.hibernate.search.indexes.impl.SharingBufferReaderProvider.openIndexReader(SharingBufferReaderProvider.java:35) ~[hibernate-search-engine-5.8.0.Beta4.jar:5.8.0.Beta4]
> at org.hibernate.search.reader.impl.ManagedMultiReader.createInstance(ManagedMultiReader.java:69) ~[hibernate-search-engine-5.8.0.Beta4.jar:5.8.0.Beta4]
> at org.hibernate.search.reader.impl.MultiReaderFactory.openReader(MultiReaderFactory.java:48) ~[hibernate-search-engine-5.8.0.Beta4.jar:5.8.0.Beta4]
> at org.hibernate.search.query.engine.impl.LuceneHSQuery.buildSearcher(LuceneHSQuery.java:475) ~[hibernate-search-engine-5.8.0.Beta4.jar:5.8.0.Beta4]
> at org.hibernate.search.query.engine.impl.LuceneHSQuery.buildSearcher(LuceneHSQuery.java:399) ~[hibernate-search-engine-5.8.0.Beta4.jar:5.8.0.Beta4]
> at org.hibernate.search.query.engine.impl.LuceneHSQuery.queryEntityInfos(LuceneHSQuery.java:142) ~[hibernate-search-engine-5.8.0.Beta4.jar:5.8.0.Beta4]
> at org.infinispan.query.impl.CacheQueryImpl.list(CacheQueryImpl.java:160) ~[classes/:?]
> at org.infinispan.query.blackbox.ClusteredCacheTest.testCompute(ClusteredCacheTest.java:687) ~[test-classes/:?]
> Caused by: org.apache.lucene.index.IndexNotFoundException: no segments* file found in InfinispanDirectory{indexName='person.194'}: files: []
> at org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:726) ~[lucene-core-5.5.4.jar:5.5.4 31012120ebbd93744753eb37f1dbc5e654628291 - jpountz - 2017-02-08 19:08:03]
> at org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:683) ~[lucene-core-5.5.4.jar:5.5.4 31012120ebbd93744753eb37f1dbc5e654628291 - jpountz - 2017-02-08 19:08:03]
> at org.apache.lucene.index.SegmentInfos.readLatestCommit(SegmentInfos.java:490) ~[lucene-core-5.5.4.jar:5.5.4 31012120ebbd93744753eb37f1dbc5e654628291 - jpountz - 2017-02-08 19:08:03]
> at org.apache.lucene.index.StandardDirectoryReader.isCurrent(StandardDirectoryReader.java:344) ~[lucene-core-5.5.4.jar:5.5.4 31012120ebbd93744753eb37f1dbc5e654628291 - jpountz - 2017-02-08 19:08:03]
> at org.apache.lucene.index.StandardDirectoryReader.doOpenNoWriter(StandardDirectoryReader.java:300) ~[lucene-core-5.5.4.jar:5.5.4 31012120ebbd93744753eb37f1dbc5e654628291 - jpountz - 2017-02-08 19:08:03]
> at org.apache.lucene.index.StandardDirectoryReader.doOpenIfChanged(StandardDirectoryReader.java:263) ~[lucene-core-5.5.4.jar:5.5.4 31012120ebbd93744753eb37f1dbc5e654628291 - jpountz - 2017-02-08 19:08:03]
> at org.apache.lucene.index.StandardDirectoryReader.doOpenIfChanged(StandardDirectoryReader.java:251) ~[lucene-core-5.5.4.jar:5.5.4 31012120ebbd93744753eb37f1dbc5e654628291 - jpountz - 2017-02-08 19:08:03]
> at org.apache.lucene.index.DirectoryReader.openIfChanged(DirectoryReader.java:137) ~[lucene-core-5.5.4.jar:5.5.4 31012120ebbd93744753eb37f1dbc5e654628291 - jpountz - 2017-02-08 19:08:03]
> at org.hibernate.search.indexes.impl.SharingBufferReaderProvider$PerDirectoryLatestReader.refreshAndGet(SharingBufferReaderProvider.java:239) ~[hibernate-search-engine-5.8.0.Beta4.jar:5.8.0.Beta4]
> ... 35 more
> {noformat}
> I suspect the root problem is that trace logging makes everything slower.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 5 months
[JBoss JIRA] (ISPN-8160) ClusteredCacheWithAffinityIndexManagerTxTest random failures with trace logging enabled
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-8160?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-8160:
------------------------------------
Got some timeout failures in CI even without trace logging:
https://ci.infinispan.org/job/InfinispanAlternateBuilds/job/InfinispanJDK...
https://ci.infinispan.org/job/InfinispanAlternateBuilds/job/InfinispanJDK...
> ClusteredCacheWithAffinityIndexManagerTxTest random failures with trace logging enabled
> ---------------------------------------------------------------------------------------
>
> Key: ISPN-8160
> URL: https://issues.jboss.org/browse/ISPN-8160
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Query
> Affects Versions: 9.1.0.Final
> Reporter: Dan Berindei
> Assignee: Gustavo Fernandes
> Priority: Critical
> Labels: testsuite_stability
>
> The test usually passes when run by itself, but when run in parallel with other tests often getting one or more failures. The failing test method is not always the same, e.g.
> {noformat}
> 13:10:28,264 ERROR (testng-Test:[]) [TestSuiteProgress] Test failed: org.infinispan.query.blackbox.ClusteredCacheWithAffinityIndexManagerTxTest.testCompute
> org.hibernate.search.exception.SearchException: Unable to reopen IndexReader
> at org.hibernate.search.indexes.impl.SharingBufferReaderProvider$PerDirectoryLatestReader.refreshAndGet(SharingBufferReaderProvider.java:242) ~[hibernate-search-engine-5.8.0.Beta4.jar:5.8.0.Beta4]
> at org.hibernate.search.indexes.impl.SharingBufferReaderProvider.openIndexReader(SharingBufferReaderProvider.java:73) ~[hibernate-search-engine-5.8.0.Beta4.jar:5.8.0.Beta4]
> at org.hibernate.search.indexes.impl.SharingBufferReaderProvider.openIndexReader(SharingBufferReaderProvider.java:35) ~[hibernate-search-engine-5.8.0.Beta4.jar:5.8.0.Beta4]
> at org.hibernate.search.reader.impl.ManagedMultiReader.createInstance(ManagedMultiReader.java:69) ~[hibernate-search-engine-5.8.0.Beta4.jar:5.8.0.Beta4]
> at org.hibernate.search.reader.impl.MultiReaderFactory.openReader(MultiReaderFactory.java:48) ~[hibernate-search-engine-5.8.0.Beta4.jar:5.8.0.Beta4]
> at org.hibernate.search.query.engine.impl.LuceneHSQuery.buildSearcher(LuceneHSQuery.java:475) ~[hibernate-search-engine-5.8.0.Beta4.jar:5.8.0.Beta4]
> at org.hibernate.search.query.engine.impl.LuceneHSQuery.buildSearcher(LuceneHSQuery.java:399) ~[hibernate-search-engine-5.8.0.Beta4.jar:5.8.0.Beta4]
> at org.hibernate.search.query.engine.impl.LuceneHSQuery.queryEntityInfos(LuceneHSQuery.java:142) ~[hibernate-search-engine-5.8.0.Beta4.jar:5.8.0.Beta4]
> at org.infinispan.query.impl.CacheQueryImpl.list(CacheQueryImpl.java:160) ~[classes/:?]
> at org.infinispan.query.blackbox.ClusteredCacheTest.testCompute(ClusteredCacheTest.java:687) ~[test-classes/:?]
> Caused by: org.apache.lucene.index.IndexNotFoundException: no segments* file found in InfinispanDirectory{indexName='person.194'}: files: []
> at org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:726) ~[lucene-core-5.5.4.jar:5.5.4 31012120ebbd93744753eb37f1dbc5e654628291 - jpountz - 2017-02-08 19:08:03]
> at org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:683) ~[lucene-core-5.5.4.jar:5.5.4 31012120ebbd93744753eb37f1dbc5e654628291 - jpountz - 2017-02-08 19:08:03]
> at org.apache.lucene.index.SegmentInfos.readLatestCommit(SegmentInfos.java:490) ~[lucene-core-5.5.4.jar:5.5.4 31012120ebbd93744753eb37f1dbc5e654628291 - jpountz - 2017-02-08 19:08:03]
> at org.apache.lucene.index.StandardDirectoryReader.isCurrent(StandardDirectoryReader.java:344) ~[lucene-core-5.5.4.jar:5.5.4 31012120ebbd93744753eb37f1dbc5e654628291 - jpountz - 2017-02-08 19:08:03]
> at org.apache.lucene.index.StandardDirectoryReader.doOpenNoWriter(StandardDirectoryReader.java:300) ~[lucene-core-5.5.4.jar:5.5.4 31012120ebbd93744753eb37f1dbc5e654628291 - jpountz - 2017-02-08 19:08:03]
> at org.apache.lucene.index.StandardDirectoryReader.doOpenIfChanged(StandardDirectoryReader.java:263) ~[lucene-core-5.5.4.jar:5.5.4 31012120ebbd93744753eb37f1dbc5e654628291 - jpountz - 2017-02-08 19:08:03]
> at org.apache.lucene.index.StandardDirectoryReader.doOpenIfChanged(StandardDirectoryReader.java:251) ~[lucene-core-5.5.4.jar:5.5.4 31012120ebbd93744753eb37f1dbc5e654628291 - jpountz - 2017-02-08 19:08:03]
> at org.apache.lucene.index.DirectoryReader.openIfChanged(DirectoryReader.java:137) ~[lucene-core-5.5.4.jar:5.5.4 31012120ebbd93744753eb37f1dbc5e654628291 - jpountz - 2017-02-08 19:08:03]
> at org.hibernate.search.indexes.impl.SharingBufferReaderProvider$PerDirectoryLatestReader.refreshAndGet(SharingBufferReaderProvider.java:239) ~[hibernate-search-engine-5.8.0.Beta4.jar:5.8.0.Beta4]
> ... 35 more
> {noformat}
> I suspect the root problem is that trace logging makes everything slower.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 5 months