March 2016 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-6055) Performance regression in replicated reads after ISPN-5465 and ISPN-5878

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-6055?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-6055: ------------------------------ Fix Version/s: 9.0.0.Alpha1 (was: 8.2.0.Final) > Performance regression in replicated reads after ISPN-5465 and ISPN-5878 > ------------------------------------------------------------------------ > > Key: ISPN-6055 > URL: https://issues.jboss.org/browse/ISPN-6055 > Project: Infinispan > Issue Type: Bug > Components: Core > Reporter: Jakub Markos > Assignee: Dan Berindei > Fix For: 9.0.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-6041) Remote Listeners: Client event reader thread reports EOF as error

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-6041?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-6041: ------------------------------ Fix Version/s: 9.0.0.Alpha1 (was: 8.2.0.Final) > Remote Listeners: Client event reader thread reports EOF as error > ----------------------------------------------------------------- > > Key: ISPN-6041 > URL: https://issues.jboss.org/browse/ISPN-6041 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols > Affects Versions: 8.1.0.Final > Reporter: Dan Berindei > Priority: Minor > Fix For: 9.0.0.Alpha1 > > > {noformat} > 14:02:14,904 ERROR (Client-Listener-87aa07aee56d43e1) [ClientListenerNotifier] ISPN004043: Unrecoverable error reading event from server /127.0.0.1:15530, exiting event reader thread > org.infinispan.client.hotrod.exceptions.TransportException: End of stream reached! > at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransport.readByte(TcpTransport.java:198) > at org.infinispan.client.hotrod.impl.protocol.Codec20.readMagic(Codec20.java:305) > at org.infinispan.client.hotrod.impl.protocol.Codec20.readEvent(Codec20.java:147) > at org.infinispan.client.hotrod.event.ClientListenerNotifier$EventDispatcher.run(ClientListenerNotifier.java:252) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-6040) FunctionalNonTxBackupOwnerBecomingPrimaryOwnerTest.testPrimaryOwnerChangingDuringRemove random failures

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-6040?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-6040: ------------------------------ Fix Version/s: 9.0.0.Alpha1 (was: 8.2.0.Final) > FunctionalNonTxBackupOwnerBecomingPrimaryOwnerTest.testPrimaryOwnerChangingDuringRemove random failures > ------------------------------------------------------------------------------------------------------- > > Key: ISPN-6040 > URL: https://issues.jboss.org/browse/ISPN-6040 > Project: Infinispan > Issue Type: Bug > Components: Core, Test Suite - Core > Affects Versions: 8.1.0.Final > Reporter: Dan Berindei > Assignee: Galder Zamarreño > Priority: Blocker > Labels: testsuite_stability > Fix For: 9.0.0.Alpha1 > > > Similar to ISPN-6039, the test failure is caused by the state transfer put happening after the test's remove. > In this case, the command types are different, so blocking works correctly. However, when the {{ReadWriteKeyValueCommand}} executes before the state transfer put, it doesn't find any value, and it doesn't commit the entry. This means the key is not added to {{CommitManager}}'s {{tracker}} map, and the state transfer put is allowed to write to it - effectively undoing the remove. > {noformat} > java.lang.AssertionError: expected:<null> but was:<v0> > 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:88) > at org.infinispan.distribution.rehash.NonTxBackupOwnerBecomingPrimaryOwnerTest.doTest(NonTxBackupOwnerBecomingPrimaryOwnerTest.java:194) > at org.infinispan.functional.distribution.rehash.FunctionalNonTxBackupOwnerBecomingPrimaryOwnerTest.testPrimaryOwnerChangingDuringRemove(FunctionalNonTxBackupOwnerBecomingPrimaryOwnerTest.java:103) > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-6285) SharedReplMassIndexTest hanging during cluster shutdown

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-6285?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-6285: ------------------------------ Fix Version/s: 9.0.0.Alpha1 (was: 8.2.0.Final) > SharedReplMassIndexTest hanging during cluster shutdown > ------------------------------------------------------- > > Key: ISPN-6285 > URL: https://issues.jboss.org/browse/ISPN-6285 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Query > Affects Versions: 8.2.0.Beta2 > Reporter: Dan Berindei > Labels: testsuite_stability > Fix For: 9.0.0.Alpha1 > > > No logs for now, just a log from CI showing the query test suite hanging for 2+ hours, and this is the only active thread at the end: > {noformat} > "testng-SharedReplMassIndexTest" #15 prio=5 os_prio=0 tid=0x00007fc4a07ca000 nid=0x7314 waiting on condition [0x00007fc465efb000] > java.lang.Thread.State: TIMED_WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x00000000d9d092b8> (a java.util.concurrent.CountDownLatch$Sync) > at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) > at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037) > at java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328) > at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277) > at org.hibernate.search.backend.impl.lucene.SyncWorkProcessor.shutdown(SyncWorkProcessor.java:117) > at org.hibernate.search.backend.impl.lucene.LuceneBackendQueueProcessor.close(LuceneBackendQueueProcessor.java:69) > at org.infinispan.query.indexmanager.LocalIndexingBackend.flushAndClose(LocalIndexingBackend.java:48) > at org.infinispan.query.indexmanager.ClusteredSwitchingBackend.closeBackend(ClusteredSwitchingBackend.java:227) > at org.infinispan.query.indexmanager.ClusteredSwitchingBackend.shutdown(ClusteredSwitchingBackend.java:216) > at org.infinispan.query.indexmanager.InfinispanBackendQueueProcessor.close(InfinispanBackendQueueProcessor.java:79) > at org.hibernate.search.indexes.spi.DirectoryBasedIndexManager.destroy(DirectoryBasedIndexManager.java:78) > at org.hibernate.search.indexes.impl.IndexManagerHolder.stop(IndexManagerHolder.java:197) > - locked <0x00000000a3832138> (a org.hibernate.search.indexes.impl.IndexManagerHolder) > at org.hibernate.search.engine.impl.ImmutableSearchFactory.close(ImmutableSearchFactory.java:230) > at org.hibernate.search.engine.impl.MutableSearchFactory.close(MutableSearchFactory.java:137) > at org.infinispan.query.impl.LifecycleManager.cacheStopping(LifecycleManager.java:296) > at org.infinispan.factories.ComponentRegistry.stop(ComponentRegistry.java:244) > at org.infinispan.cache.impl.CacheImpl.stop(CacheImpl.java:869) > at org.infinispan.cache.impl.CacheImpl.stop(CacheImpl.java:864) > at org.infinispan.test.TestingUtil.killCaches(TestingUtil.java:798) > at org.infinispan.test.TestingUtil.killCacheManagers(TestingUtil.java:633) > at org.infinispan.test.TestingUtil.killCacheManagers(TestingUtil.java:626) > at org.infinispan.test.TestingUtil.killCacheManagers(TestingUtil.java:622) > at org.infinispan.test.MultipleCacheManagersTest.destroy(MultipleCacheManagersTest.java:87) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84) > at org.testng.internal.Invoker.invokeConfigurationMethod(Invoker.java:564) > at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:213) > at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:138) > at org.testng.internal.TestMethodWorker.invokeAfterClassMethods(TestMethodWorker.java:225) > at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:114) > at org.testng.TestRunner.privateRun(TestRunner.java:767) > at org.testng.TestRunner.run(TestRunner.java:617) > at org.testng.SuiteRunner.runTest(SuiteRunner.java:348) > at org.testng.SuiteRunner.access$000(SuiteRunner.java:38) > at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:382) > at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-6252) Upgrade to Apache Lucene 5.5

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-6252?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-6252: ------------------------------ Fix Version/s: 9.0.0.Alpha1 (was: 8.2.0.Final) > Upgrade to Apache Lucene 5.5 > ---------------------------- > > Key: ISPN-6252 > URL: https://issues.jboss.org/browse/ISPN-6252 > Project: Infinispan > Issue Type: Component Upgrade > Components: Embedded Querying > Reporter: Sanne Grinovero > Assignee: Gustavo Fernandes > Fix For: 9.0.0.Alpha1 > > > Apache Lucene 5.5 is released now, and is "drop-in compatible" with versions 5.3 and 5.4 so you don't have to wait for an Hibernate Search release. > It's also being the last one for the 5.x series before 6, so I expect that we'll see some more micro releases for maintenance but essentially that this will be some form of long term commitment. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-6245) Remote query should be able to work with JBoss marshaling, compat mode and hibernate-search annotations

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-6245?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-6245: ------------------------------ Fix Version/s: 9.0.0.Alpha1 (was: 8.2.0.Final) > Remote query should be able to work with JBoss marshaling, compat mode and hibernate-search annotations > ------------------------------------------------------------------------------------------------------- > > Key: ISPN-6245 > URL: https://issues.jboss.org/browse/ISPN-6245 > Project: Infinispan > Issue Type: Enhancement > Components: Remote Querying > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 9.0.0.Alpha1 > > > This currently requires protobuf marshalling but it should be possible to make it work with JBoss marshalling too. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-6224) Simplify configuration of Query with Indexing Affinity

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-6224?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-6224: ------------------------------ Fix Version/s: 9.0.0.Alpha1 (was: 8.2.0.Final) > Simplify configuration of Query with Indexing Affinity > ------------------------------------------------------ > > Key: ISPN-6224 > URL: https://issues.jboss.org/browse/ISPN-6224 > Project: Infinispan > Issue Type: Enhancement > Components: Embedded Querying > Reporter: Sanne Grinovero > Fix For: 9.0.0.Alpha1 > > > We should try to enable the "Index Affinity" capabilities in an easier way from a configuration point of view. > For example I wonder if the capabilities provided by the {{AffinityPartitioner}} could not be enabled by default, for example automatically decorating any user defined {{HashFunctionPartitioner}} so that people can't neither forget to enable it, nor override it. > Second, should it be enabled by default when the cache configuration suggests it, for example in most clustered caches? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-6220) Speedup index rebuilds but using ADD rather than UPDATE statements when safe

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-6220?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-6220: ------------------------------ Fix Version/s: 9.0.0.Alpha1 (was: 8.2.0.Final) > Speedup index rebuilds but using ADD rather than UPDATE statements when safe > ---------------------------------------------------------------------------- > > Key: ISPN-6220 > URL: https://issues.jboss.org/browse/ISPN-6220 > Project: Infinispan > Issue Type: Enhancement > Components: Embedded Querying > Reporter: Sanne Grinovero > Fix For: 9.0.0.Alpha1 > > > The {{DistributedExecutorMassIndexer}} relies on update commands to index the new entries, but when we just run a full purge of the index it should be safe to use Add commands instead if we know that there aren't concurrent updates. > The lack of concurrent updates might be tricky but I think we can find such a condition when using Affinity as the index is being fully controlled by the current indexing engine, similarly to the checks to see if it's safe to use an NRT workspace. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-6219) An interruption during a MassIndexer run should exit early

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-6219?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-6219: ------------------------------ Fix Version/s: 9.0.0.Alpha1 (was: 8.2.0.Final) > An interruption during a MassIndexer run should exit early > ---------------------------------------------------------- > > Key: ISPN-6219 > URL: https://issues.jboss.org/browse/ISPN-6219 > Project: Infinispan > Issue Type: Bug > Components: Embedded Querying > Reporter: Sanne Grinovero > Fix For: 9.0.0.Alpha1 > > > Methods like {{IndexUpdater.updateIndex()}} correctly check for interruption state to skip some work but they don't trigger an early exit from the indexing loop so we'd still be consuming all of the data stream. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-6212) InfinispanBackendQueueProcessor is assuming all IndexManager implementations are DirectoryBasedIndexManager

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-6212?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-6212: ------------------------------ Fix Version/s: 9.0.0.Alpha1 (was: 8.2.0.Final) > InfinispanBackendQueueProcessor is assuming all IndexManager implementations are DirectoryBasedIndexManager > ----------------------------------------------------------------------------------------------------------- > > Key: ISPN-6212 > URL: https://issues.jboss.org/browse/ISPN-6212 > Project: Infinispan > Issue Type: Task > Components: Embedded Querying > Reporter: Sanne Grinovero > Fix For: 9.0.0.Alpha1 > > > See also the FIXME note in {{InfinispanBackendQueueProcessor}}: this needs to be cleaned up. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues March 2016