[JBoss JIRA] (ISPN-8432) TopologyChangeFunctionalTest.testOriginatorLeft fails randomly
by Dan Berindei (Jira)
[ https://issues.jboss.org/browse/ISPN-8432?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-8432:
------------------------------------
Always fails with a different error now [~pruivo]
{noformat}
java.lang.AssertionError: [XID=Xid{formatId=-1234, globalTransactionId=00000003,branchQualifier=00000003}] Wrong XA return code for commit expected:<0> but was:<-3>
at org.testng.AssertJUnit.fail(AssertJUnit.java:59)
at org.testng.AssertJUnit.failNotEquals(AssertJUnit.java:364)
at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:80)
at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:245)
at org.infinispan.server.hotrod.test.RemoteTransaction.commitAndAssert(RemoteTransaction.java:124)
at org.infinispan.server.hotrod.tx.TopologyChangeFunctionalTest.testOriginatorLeft(TopologyChangeFunctionalTest.java:136)
{noformat}
> TopologyChangeFunctionalTest.testOriginatorLeft fails randomly
> --------------------------------------------------------------
>
> Key: ISPN-8432
> URL: https://issues.jboss.org/browse/ISPN-8432
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Server
> Affects Versions: 9.2.0.Alpha1
> Environment: Jenkins
> Reporter: Tristan Tarrant
> Assignee: Pedro Ruivo
> Priority: Major
> Labels: testsuite_stability
>
> http://ci.infinispan.org/job/Infinispan/job/PR-5506/3/testReport/junit/or...
> java.lang.AssertionError: Status should have been 'Success' but instead was: 'KeyDoesNotExist'
> at org.infinispan.server.hotrod.test.HotRodTestingUtil.assertStatus(HotRodTestingUtil.java:265)
> at org.infinispan.server.hotrod.test.HotRodTestingUtil.assertSuccess(HotRodTestingUtil.java:271)
> at org.infinispan.server.hotrod.tx.TopologyChangeFunctionalTest.assertData(TopologyChangeFunctionalTest.java:227)
> at org.infinispan.server.hotrod.tx.TopologyChangeFunctionalTest.testOriginatorLeft(TopologyChangeFunctionalTest.java:126)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> ... Removed 18 stack frames
>
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 3 months
[JBoss JIRA] (ISPN-9890) Query doesn't stop properly after index data loss
by Dan Berindei (Jira)
Dan Berindei created ISPN-9890:
----------------------------------
Summary: Query doesn't stop properly after index data loss
Key: ISPN-9890
URL: https://issues.jboss.org/browse/ISPN-9890
Project: Infinispan
Issue Type: Bug
Components: Embedded Querying
Affects Versions: 9.4.5.Final, 10.0.0.Alpha2
Reporter: Dan Berindei
Fix For: 10.0.0.Beta1
When index cache entries are lost (e.g. because a test didn't override {{clearContent()}} to clear the indexes properly before stopping the manager), the query module throws an exception during stop:
{noformat}
18:41:36,669 ERROR (testng-Test) [ComponentRegistry] ISPN000538: Error stopping module org.infinispan.query.impl.LifecycleManager:___defaultcache
java.lang.AssertionError: file _0.cfe does not exist; files=[]
at org.apache.lucene.index.IndexWriter.filesExist(IndexWriter.java:4338) ~[lucene-core-5.5.5.jar:5.5.5 b3441673c21c83762035dc21d3827ad16aa17b68 - sarowe - 2017-10-20 08:57:09]
at org.apache.lucene.index.IndexWriter.startCommit(IndexWriter.java:4409) ~[lucene-core-5.5.5.jar:5.5.5 b3441673c21c83762035dc21d3827ad16aa17b68 - sarowe - 2017-10-20 08:57:09]
at org.apache.lucene.index.IndexWriter.prepareCommitInternal(IndexWriter.java:2865) ~[lucene-core-5.5.5.jar:5.5.5 b3441673c21c83762035dc21d3827ad16aa17b68 - sarowe - 2017-10-20 08:57:09]
at org.apache.lucene.index.IndexWriter.commitInternal(IndexWriter.java:2970) ~[lucene-core-5.5.5.jar:5.5.5 b3441673c21c83762035dc21d3827ad16aa17b68 - sarowe - 2017-10-20 08:57:09]
at org.apache.lucene.index.IndexWriter.shutdown(IndexWriter.java:1082) ~[lucene-core-5.5.5.jar:5.5.5 b3441673c21c83762035dc21d3827ad16aa17b68 - sarowe - 2017-10-20 08:57:09]
at org.apache.lucene.index.IndexWriter.close(IndexWriter.java:1125) ~[lucene-core-5.5.5.jar:5.5.5 b3441673c21c83762035dc21d3827ad16aa17b68 - sarowe - 2017-10-20 08:57:09]
at org.hibernate.search.backend.impl.lucene.IndexWriterHolder.closeIndexWriter(IndexWriterHolder.java:173) ~[hibernate-search-engine-5.10.3.Final.jar:5.10.3.Final]
at org.hibernate.search.backend.impl.lucene.AbstractWorkspaceImpl.closeIndexWriter(AbstractWorkspaceImpl.java:109) ~[hibernate-search-engine-5.10.3.Final.jar:5.10.3.Final]
at org.hibernate.search.backend.impl.lucene.AbstractWorkspaceImpl.shutDownNow(AbstractWorkspaceImpl.java:104) ~[hibernate-search-engine-5.10.3.Final.jar:5.10.3.Final]
at org.hibernate.search.backend.impl.lucene.LuceneBackendResources.shutdown(LuceneBackendResources.java:103) ~[hibernate-search-engine-5.10.3.Final.jar:5.10.3.Final]
at org.hibernate.search.backend.impl.lucene.WorkspaceHolder.close(WorkspaceHolder.java:68) ~[hibernate-search-engine-5.10.3.Final.jar:5.10.3.Final]
at org.hibernate.search.util.impl.Closer.push(Closer.java:92) ~[hibernate-search-engine-5.10.3.Final.jar:5.10.3.Final]
at org.hibernate.search.util.impl.Closer.push(Closer.java:107) ~[hibernate-search-engine-5.10.3.Final.jar:5.10.3.Final]
at org.hibernate.search.indexes.spi.DirectoryBasedIndexManager.destroy(DirectoryBasedIndexManager.java:76) ~[hibernate-search-engine-5.10.3.Final.jar:5.10.3.Final]
at org.hibernate.search.indexes.impl.IndexManagerGroupHolder.close(IndexManagerGroupHolder.java:80) ~[hibernate-search-engine-5.10.3.Final.jar:5.10.3.Final]
at org.hibernate.search.util.impl.Closer.push(Closer.java:92) ~[hibernate-search-engine-5.10.3.Final.jar:5.10.3.Final]
at org.hibernate.search.util.impl.Closer.pushAll(Closer.java:120) ~[hibernate-search-engine-5.10.3.Final.jar:5.10.3.Final]
at org.hibernate.search.indexes.impl.IndexManagerHolder.stop(IndexManagerHolder.java:186) ~[hibernate-search-engine-5.10.3.Final.jar:5.10.3.Final]
at org.hibernate.search.util.impl.Closer.push(Closer.java:92) ~[hibernate-search-engine-5.10.3.Final.jar:5.10.3.Final]
at org.hibernate.search.util.impl.Closer.push(Closer.java:107) ~[hibernate-search-engine-5.10.3.Final.jar:5.10.3.Final]
at org.hibernate.search.engine.impl.ImmutableSearchFactory.close(ImmutableSearchFactory.java:268) ~[hibernate-search-engine-5.10.3.Final.jar:5.10.3.Final]
at org.hibernate.search.engine.impl.MutableSearchFactory.close(MutableSearchFactory.java:133) ~[hibernate-search-engine-5.10.3.Final.jar:5.10.3.Final]
at org.infinispan.query.impl.LifecycleManager.cacheStopping(LifecycleManager.java:411) ~[classes/:?]
at org.infinispan.factories.ComponentRegistry.preStop(ComponentRegistry.java:200) [classes/:?]
at org.infinispan.factories.AbstractComponentRegistry.stop(AbstractComponentRegistry.java:373) [classes/:?]
at org.infinispan.cache.impl.CacheImpl.performImmediateShutdown(CacheImpl.java:1159) [classes/:?]
at org.infinispan.cache.impl.CacheImpl.stop(CacheImpl.java:1124) [classes/:?]
at org.infinispan.cache.impl.AbstractDelegatingCache.stop(AbstractDelegatingCache.java:520) [classes/:?]
at org.infinispan.cache.impl.AbstractDelegatingCache.stop(AbstractDelegatingCache.java:520) [classes/:?]
at org.infinispan.cache.impl.AbstractDelegatingCache.stop(AbstractDelegatingCache.java:520) [classes/:?]
at org.infinispan.manager.DefaultCacheManager.terminate(DefaultCacheManager.java:734) [classes/:?]
at org.infinispan.manager.DefaultCacheManager.stopCaches(DefaultCacheManager.java:786) [classes/:?]
at org.infinispan.manager.DefaultCacheManager.stop(DefaultCacheManager.java:762) [classes/:?]
at org.infinispan.test.TestingUtil.killCacheManagers(TestingUtil.java:847) [test-classes/:?]
at org.infinispan.test.MultipleCacheManagersTest.clearContent(MultipleCacheManagersTest.java:158) [test-classes/:?]
{noformat}
When this exception appears, all but the first {{SyncWorkProcessor}} threads are leaked. Interesting enough, in {{ClusteredCachePerfIspnTest}} the exception is only thrown when stopping node B -- node A stops cleanly and all {{SyncWorkProcessor}} threads are stopped.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 3 months
[JBoss JIRA] (ISPN-4093) Inefficient implementation of containsKey in distribute cache for large entries
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-4093?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant reassigned ISPN-4093:
-------------------------------------
Assignee: Dan Berindei
> Inefficient implementation of containsKey in distribute cache for large entries
> -------------------------------------------------------------------------------
>
> Key: ISPN-4093
> URL: https://issues.jboss.org/browse/ISPN-4093
> Project: Infinispan
> Issue Type: Enhancement
> Components: Core
> Affects Versions: 6.0.0.Final
> Reporter: Mikolaj Gierulski
> Assignee: Dan Berindei
> Priority: Minor
> Labels: contains, dist
>
> As far as I understand, containsKey on distributed cache performs a GetKeyValueCommand (which may be executed remotedly) and checks if the result was null.
> This results in loading the whole entry, which may be expensive when dealing with large entries.
> In our system we introduced a KeyExistsTask implementing DistributedCallable, which we submit with distributed execution framework. This task performs cache.containsKey on keys local node avoiding unnecessary transfer of possibly large amount of data.
> In our case this brought a significant improvement of containsKey operation.
> Best regards,
> Mikolaj
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 3 months
[JBoss JIRA] (ISPN-9883) Control cluster configuration
by Gustavo Fernandes (Jira)
[ https://issues.jboss.org/browse/ISPN-9883?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes updated ISPN-9883:
------------------------------------
Description:
The operator assumes a config map is populated with the configuration to be used. We should support other types of configuration. Proposal:
* type=Custom: the user provides a configmap where the config is located
* type=Stateless: it will start a cluster with cloud.xml without stable persistence
* type=Stateful: it will start a cluster backed by a stateful set: the data/ directory will be the stable storage
* type=Default: no configuration provided, will start a type=Stateless cluster
was:
The operator assumes a config map is populated with the configuration to be used. We should support other types of configuration. Proposal:
* type=Custom: the user provides a configmap where the config is located
* type=Stateless: it will start a cluster with cloud.xml and in memory storage only
* type=Stateful: it will start a cluster backed by a stateful set
* type=Default: no configuration provided, will start a type=Stateless cluster
> Control cluster configuration
> ------------------------------
>
> Key: ISPN-9883
> URL: https://issues.jboss.org/browse/ISPN-9883
> Project: Infinispan
> Issue Type: Feature Request
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
> Priority: Major
>
> The operator assumes a config map is populated with the configuration to be used. We should support other types of configuration. Proposal:
> * type=Custom: the user provides a configmap where the config is located
> * type=Stateless: it will start a cluster with cloud.xml without stable persistence
> * type=Stateful: it will start a cluster backed by a stateful set: the data/ directory will be the stable storage
> * type=Default: no configuration provided, will start a type=Stateless cluster
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 3 months
[JBoss JIRA] (ISPN-9883) Control cluster configuration
by Gustavo Fernandes (Jira)
[ https://issues.jboss.org/browse/ISPN-9883?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes updated ISPN-9883:
------------------------------------
Description:
The operator assumes a config map is populated with the configuration to be used. We should support other types of configuration. Proposal:
* type=Custom: the user provides a configmap where the config is located
* type=Statefull: it will start a cluster backed by a stateful set: the data/ directory will be the stable storage
* type=Stateless: it will start a cluster with cloud.xml without stable persistence
* type=Default: no configuration provided, will start a type=Stateless cluster
was:
The operator assumes a config map is populated with the configuration to be used. We should support other types of configuration. Proposal:
* type=Custom: the user provides a configmap where the config is located
* type=Stateless: it will start a cluster with cloud.xml without stable persistence
* type=Stateful: it will start a cluster backed by a stateful set: the data/ directory will be the stable storage
* type=Default: no configuration provided, will start a type=Stateless cluster
> Control cluster configuration
> ------------------------------
>
> Key: ISPN-9883
> URL: https://issues.jboss.org/browse/ISPN-9883
> Project: Infinispan
> Issue Type: Feature Request
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
> Priority: Major
>
> The operator assumes a config map is populated with the configuration to be used. We should support other types of configuration. Proposal:
> * type=Custom: the user provides a configmap where the config is located
> * type=Statefull: it will start a cluster backed by a stateful set: the data/ directory will be the stable storage
> * type=Stateless: it will start a cluster with cloud.xml without stable persistence
> * type=Default: no configuration provided, will start a type=Stateless cluster
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 3 months
[JBoss JIRA] (ISPN-9888) Docs: Default JGroups for Infinispan
by Don Naro (Jira)
Don Naro created ISPN-9888:
------------------------------
Summary: Docs: Default JGroups for Infinispan
Key: ISPN-9888
URL: https://issues.jboss.org/browse/ISPN-9888
Project: Infinispan
Issue Type: Enhancement
Components: Documentation-Core
Affects Versions: 9.4.5.Final, 10.0.0.Beta2
Reporter: Don Naro
Assignee: Don Naro
Default properties in jgroups-defaults.xml are not the same as JGroups defaults.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 3 months