July 2017 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-5075) org.infinispan.IllegalLifecycleStateException in query tests

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5075?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5075: ---------------------------------- Fix Version/s: 9.2.0.Final (was: 9.1.0.Final) > org.infinispan.IllegalLifecycleStateException in query tests > ------------------------------------------------------------ > > Key: ISPN-5075 > URL: https://issues.jboss.org/browse/ISPN-5075 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Query > Affects Versions: 7.1.0.Alpha1 > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Fix For: 9.2.0.Final > > > Many query tests log an error after running: > {code} > Exception in thread "Hibernate Search: async deletion of index segments-1" org.infinispan.IllegalLifecycleStateException: ISPN000323: Cache 'LuceneIndexesMetadata' is in 'TERMINATED' state and so it does not accept new invocations. Either restart it or recreate the cache container. > at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:89) > at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:71) > at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:77) > at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:44) > at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:333) > at org.infinispan.cache.impl.CacheImpl.get(CacheImpl.java:422) > at org.infinispan.cache.impl.DecoratedCache.get(DecoratedCache.java:427) > at org.infinispan.lucene.impl.FileListOperations.getFileList(FileListOperations.java:160) > at org.infinispan.lucene.impl.FileListOperations.deleteFileName(FileListOperations.java:129) > at org.infinispan.lucene.impl.DirectoryImplementor.deleteFile(DirectoryImplementor.java:64) > at org.infinispan.lucene.impl.DirectoryLuceneV4$DeleteTask.run(DirectoryLuceneV4.java:195) > 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:745) > {code} > That error does not cause the tests to fail, and are due to the async deletes of segments recently implemented. Need to check if the executors are being flushed correctly when the cache manager stops -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5058) Document example configurations using a CacheStore to persist the Lucene index

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5058?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5058: ---------------------------------- Fix Version/s: 9.2.0.Final (was: 9.1.0.Final) > Document example configurations using a CacheStore to persist the Lucene index > ------------------------------------------------------------------------------ > > Key: ISPN-5058 > URL: https://issues.jboss.org/browse/ISPN-5058 > Project: Infinispan > Issue Type: Enhancement > Components: Documentation-Query > Reporter: Sanne Grinovero > Assignee: Gustavo Fernandes > Fix For: 9.2.0.Final > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4923) Server should allow toggling statistics at runtime

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4923?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-4923: ---------------------------------- Fix Version/s: 9.2.0.Final (was: 9.1.0.Final) > Server should allow toggling statistics at runtime > -------------------------------------------------- > > Key: ISPN-4923 > URL: https://issues.jboss.org/browse/ISPN-4923 > Project: Infinispan > Issue Type: Enhancement > Components: Server > Affects Versions: 7.0.0.CR2 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 9.2.0.Final > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4899) Update user guide regarding protobuf schema definition API

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4899?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-4899: ---------------------------------- Fix Version/s: 9.2.0.Final (was: 9.1.0.Final) > Update user guide regarding protobuf schema definition API > ---------------------------------------------------------- > > Key: ISPN-4899 > URL: https://issues.jboss.org/browse/ISPN-4899 > Project: Infinispan > Issue Type: Task > Components: Documentation-Query > Affects Versions: 7.0.0.CR2 > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 9.2.0.Final > > > Describe the usage of __protobuf_metadata cache -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4903) ServerFailureRetrySingleOwnerTest doesn't actually test client retry

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4903?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-4903: ---------------------------------- Fix Version/s: 9.2.0.Final (was: 9.1.0.Final) > ServerFailureRetrySingleOwnerTest doesn't actually test client retry > -------------------------------------------------------------------- > > Key: ISPN-4903 > URL: https://issues.jboss.org/browse/ISPN-4903 > Project: Infinispan > Issue Type: Bug > Components: Server, Test Suite - Server > Affects Versions: 7.0.0.CR2 > Reporter: Dan Berindei > Fix For: 9.2.0.Final > > Attachments: ServerFailureRetrySingleOwnerTest.java > > > With {{useSynchronization = true}} (the default, before ISPN-4166 is integrated), the {{SuspectException}} thrown by the listener is swallowed by the transaction manager and the client doesn't retry. The test doesn't pick that up because the exception is thrown _after_ the entry was updated in the data container (a regular SuspectException would be thrown before). > I changed the configuration to {{useSynchronization = false}}, but it didn't work because the {{SuspectException}} is wrapped in a {{CacheListenerException}}, so the client throws an exception instead of retrying. I also changed the test to use an interceptor instead of a listener, but then I got a {{ClassCastException}}: > {noformat} > Caused by: java.lang.ClassCastException: [B cannot be cast to org.infinispan.container.entries.CacheEntry > at org.infinispan.cache.impl.CacheImpl.getCacheEntry(CacheImpl.java:424) > at org.infinispan.cache.impl.CacheImpl.getCacheEntry(CacheImpl.java:429) > at org.infinispan.server.hotrod.Decoder2x$.customReadKey(Decoder2x.scala:285) > at org.infinispan.server.hotrod.HotRodDecoder.customDecodeKey(HotRodDecoder.scala:156) > at org.infinispan.server.core.AbstractProtocolDecoder.org$infinispan$server$core$AbstractProtocolDecoder$$decodeKey(AbstractProtocolDecoder.scala:176) > at org.infinispan.server.core.AbstractProtocolDecoder.decodeDispatch(AbstractProtocolDecoder.scala:71) ... 14 more > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5476) Cross-site tests should run in parallel

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5476?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5476: ---------------------------------- Fix Version/s: 9.2.0.Final (was: 9.1.0.Final) > Cross-site tests should run in parallel > --------------------------------------- > > Key: ISPN-5476 > URL: https://issues.jboss.org/browse/ISPN-5476 > Project: Infinispan > Issue Type: Task > Components: Core, Cross-Site Replication, Test Suite - Core > Affects Versions: 7.2.1.Final > Reporter: Dan Berindei > Fix For: 9.2.0.Final > > > Currently the cross-site tests have to run in a single thread, and that means they're much slower than the regular core tests. > It also means they need to run with a separate Maven profile, and that (combined with their duration) makes it very unlikely for devs to run the xsite tests on their machines. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5475) Narayana should be configured to use a volatile store by default

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5475?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5475: ---------------------------------- Fix Version/s: 9.2.0.Final (was: 9.1.0.Final) > Narayana should be configured to use a volatile store by default > ---------------------------------------------------------------- > > Key: ISPN-5475 > URL: https://issues.jboss.org/browse/ISPN-5475 > Project: Infinispan > Issue Type: Task > Components: Test Suite - Core > Affects Versions: 7.2.1.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 9.2.0.Final > > > The {{jbossts-properties.xml}} configuration file in the core module configures a file store by default, and tests have to call {{TestCacheManagerFactory.markAsTransactional()}} (or one of the methods that calls it) to configure a volatile store instead. > Furthermore, the {{jbossts-properties.xml}} file is explicitly filtered out of the core tests jar, so other modules can't use it. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5470) Remote-executor threads should not block to acquire locks

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5470?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5470: ---------------------------------- Fix Version/s: 9.2.0.Final (was: 9.1.0.Final) > Remote-executor threads should not block to acquire locks > --------------------------------------------------------- > > Key: ISPN-5470 > URL: https://issues.jboss.org/browse/ISPN-5470 > Project: Infinispan > Issue Type: Task > Components: Core > Affects Versions: 7.2.1.Final > Reporter: Dan Berindei > Fix For: 9.2.0.Final > > > Currently, enabling the queue on the remote-executor thread pool can cause deadlocks, because a CommitCommand/1PCPrepareCommand could end up in the queue while a remote-executor thread is busy waiting to acquire the same lock that this commit would release. > If trying to acquire a lock would free the thread until the key has been acquired, we could enable the queue on the remote-executor/OOB thread pools, and we would need a lot less threads for the same load. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5454) XSite: RetryMechanismTest random failures

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5454?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5454: ---------------------------------- Fix Version/s: 9.2.0.Final (was: 9.1.0.Final) > XSite: RetryMechanismTest random failures > ----------------------------------------- > > Key: ISPN-5454 > URL: https://issues.jboss.org/browse/ISPN-5454 > Project: Infinispan > Issue Type: Bug > Components: Cross-Site Replication > Affects Versions: 7.2.1.Final > Reporter: Dan Berindei > Priority: Blocker > Labels: testsuite_stability > Fix For: 9.2.0.Final > > > {{ClusteredCacheBackupReceiver.awaitRemoteTask()}} doesn't respect the state push command's timeout, at least when it's smaller than the sync replication timeout in the target cache. When that happens, the state provider will resend the state, and there will be 2 state push commands executing at the same time. > RetryMechanismTest changes the state push timeout to 2 seconds, but the sync replication timeout stays at 15 seconds. This causes failures in {{testRetryLocally}} and {{testFailRetryLocally}}, if it takes more than 2 seconds to suspect the killed node. > {noformat} > 10:02:13,007 TRACE (asyncTransportThread-8,NodeN:) [RetryOnFailureXSiteCommand] Sending XSiteStatePushCommand{cacheName=___defaultcache, timeout=2000 (1 keys)} to [NYC (sync, timeout=2000)] > 10:02:16,008 TRACE (asyncTransportThread-8,NodeN:) [RetryOnFailureXSiteCommand] Sending XSiteStatePushCommand{cacheName=___defaultcache, timeout=2000 (1 keys)} to [NYC (sync, timeout=2000)] > 10:02:16,040 TRACE (asyncTransportThread-4,NodeP:) [RpcManagerImpl] replication exception: > org.infinispan.remoting.transport.jgroups.SuspectException: Node NodeQ-56809 was suspected > 10:02:16,040 TRACE (asyncTransportThread-0,NodeP:) [RpcManagerImpl] replication exception: > org.infinispan.remoting.transport.jgroups.SuspectException: Node NodeQ-56809 was suspected > 10:02:19,147 ERROR (testng-RetryMechanismTest:) [UnitTestTestNGListener] Test testFailRetryLocally(org.infinispan.xsite.statetransfer.failures.RetryMechanismTest) failed. > java.lang.AssertionError: expected:<2> 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.testng.AssertJUnit.assertEquals(AssertJUnit.java:252) > at org.infinispan.xsite.statetransfer.failures.RetryMechanismTest.testFailRetryLocally(RetryMechanismTest.java:227) > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5453) X-site state transfer: retry locally if local state push throws a SuspectException

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5453?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5453: ---------------------------------- Fix Version/s: 9.2.0.Final (was: 9.1.0.Final) > X-site state transfer: retry locally if local state push throws a SuspectException > ---------------------------------------------------------------------------------- > > Key: ISPN-5453 > URL: https://issues.jboss.org/browse/ISPN-5453 > Project: Infinispan > Issue Type: Bug > Components: Core, Cross-Site Replication > Affects Versions: 7.2.1.Final > Reporter: Dan Berindei > Priority: Minor > Fix For: 9.2.0.Final > > > When the local state push command throws a {{SuspectException}}, we currently retry remotely unless the target node was already removed from the cache topology. This will fail with another {{SuspectException}}, so it would be better to retry locally the first time. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 2 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues July 2017