June 2017 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-7885) "org.hibernate.search.exception.SearchException: Not a valid ScoreDoc index" under high load

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-7885?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-7885: ------------------------------------ Affects Version/s: (was: 9.1.0.Alpha1) > "org.hibernate.search.exception.SearchException: Not a valid ScoreDoc index" under high load > -------------------------------------------------------------------------------------------- > > Key: ISPN-7885 > URL: https://issues.jboss.org/browse/ISPN-7885 > Project: Infinispan > Issue Type: Bug > Affects Versions: 8.2.6.Final, 9.0.1.Final > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7885) "org.hibernate.search.exception.SearchException: Not a valid ScoreDoc index" under high load

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-7885?page=com.atlassian.jira.plugin.... ] Adrian Nistor commented on ISPN-7885: ------------------------------------- So this is no longer an issue on master? What about 9.0.x? that one still uses HSearch 5.7.0 > "org.hibernate.search.exception.SearchException: Not a valid ScoreDoc index" under high load > -------------------------------------------------------------------------------------------- > > Key: ISPN-7885 > URL: https://issues.jboss.org/browse/ISPN-7885 > Project: Infinispan > Issue Type: Bug > Affects Versions: 8.2.6.Final, 9.0.1.Final, 9.1.0.Alpha1 > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7989) SampleRemoteCacheTest always fails

by Dan Berindei (JIRA)

Dan Berindei created ISPN-7989: ---------------------------------- Summary: SampleRemoteCacheTest always fails Key: ISPN-7989 URL: https://issues.jboss.org/browse/ISPN-7989 Project: Infinispan Issue Type: Bug Components: Spring Integration Reporter: Dan Berindei Assignee: Sebastian Łaskawiec Both {{demonstrateCacheEvictionUponUpdate}} and {{clearBookCache}} fail with this error: {noformat} clearBookCache(org.infinispan.spring.provider.sample.SampleRemoteCacheTest) Time elapsed: 0.12 sec <<< FAILURE! org.infinispan.client.hotrod.exceptions.TransportException:: Could not fetch transport at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory.borrowTransportFromPool(TcpTransportFactory.java:426) at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory.getTransport(TcpTransportFactory.java:258) at org.infinispan.client.hotrod.impl.operations.FaultTolerantPingOperation.getTransport(FaultTolerantPingOperation.java:28) at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:56) at org.infinispan.client.hotrod.impl.RemoteCacheImpl.ping(RemoteCacheImpl.java:510) at org.infinispan.client.hotrod.impl.RemoteCacheImpl.resolveCompatibility(RemoteCacheImpl.java:782) at org.infinispan.client.hotrod.RemoteCacheManager.createRemoteCache(RemoteCacheManager.java:287) at org.infinispan.client.hotrod.RemoteCacheManager.getCache(RemoteCacheManager.java:157) at org.infinispan.client.hotrod.RemoteCacheManager.getCache(RemoteCacheManager.java:152) at org.infinispan.spring.provider.SpringRemoteCacheManager.getCache(SpringRemoteCacheManager.java:37) at org.infinispan.spring.provider.SpringRemoteCacheManager.getCache(SpringRemoteCacheManager.java:19) at org.infinispan.spring.provider.sample.AbstractTestTemplate.booksCache(AbstractTestTemplate.java:525) at org.infinispan.spring.provider.sample.AbstractTestTemplate.clearBookCache(AbstractTestTemplate.java:45) 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:498) 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.invokeMethod(Invoker.java:786) at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901) at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231) at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127) at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111) 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) Caused by: org.infinispan.client.hotrod.exceptions.TransportException:: Could not connect to server: /127.0.0.1:15233 at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransport.<init>(TcpTransport.java:85) at org.infinispan.client.hotrod.impl.transport.tcp.TransportObjectFactory.makeObject(TransportObjectFactory.java:38) at org.infinispan.client.hotrod.impl.transport.tcp.TransportObjectFactory.makeObject(TransportObjectFactory.java:17) at org.apache.commons.pool.impl.GenericKeyedObjectPool.borrowObject(GenericKeyedObjectPool.java:1220) at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory.borrowTransportFromPool(TcpTransportFactory.java:420) ... 34 more Caused by: java.net.ConnectException: Connection refused at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method) at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:717) at sun.nio.ch.SocketAdaptor.connect(SocketAdaptor.java:111) at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransport.<init>(TcpTransport.java:75) ... 38 more {noformat} Jenkins only shows the last 10 builds, but the last 10 have all failed. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7988) ScatteredSyncFuncTest>DistSyncFuncTest.testComputeIfAbsentFromNonOwner fails with trace logging enabled

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-7988?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-7988: ------------------------------- Component/s: Test Suite - Core > ScatteredSyncFuncTest>DistSyncFuncTest.testComputeIfAbsentFromNonOwner fails with trace logging enabled > ------------------------------------------------------------------------------------------------------- > > Key: ISPN-7988 > URL: https://issues.jboss.org/browse/ISPN-7988 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Core > Reporter: Dan Berindei > Assignee: Radim Vansa > Priority: Critical > Labels: testsuite_stability > > Every time I run the test I get this failure twice, with the same test parameters: > {noformat} > testComputeIfAbsentFromNonOwner[SCATTERED_SYNC, tx=false, numOwners=1, l1=false](org.infinispan.scattered.ScatteredSyncFuncTest) Time elapsed: 0.159 sec <<< FAILURE! > java.lang.AssertionError: expected [1] but found [0] > at org.testng.Assert.fail(Assert.java:94) > at org.testng.Assert.failNotEquals(Assert.java:494) > at org.testng.Assert.assertEquals(Assert.java:123) > at org.testng.Assert.assertEquals(Assert.java:370) > at org.testng.Assert.assertEquals(Assert.java:380) > at org.infinispan.scattered.Utils.assertOwnershipAndNonOwnership(Utils.java:49) > at org.infinispan.scattered.ScatteredSyncFuncTest.assertOwnershipAndNonOwnership(ScatteredSyncFuncTest.java:20) > at org.infinispan.distribution.BaseDistFunctionalTest.assertOnAllCachesAndOwnership(BaseDistFunctionalTest.java:162) > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7956) Investigate removing PartitionHandlingInterceptor

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-7956?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-7956: ------------------------------- Component/s: Test Suite - Core (was: Core) > Investigate removing PartitionHandlingInterceptor > ------------------------------------------------- > > Key: ISPN-7956 > URL: https://issues.jboss.org/browse/ISPN-7956 > Project: Infinispan > Issue Type: Task > Components: Test Suite - Core > Affects Versions: 9.1.0.Beta1 > Reporter: Dan Berindei > Assignee: Dan Berindei > > When all the owners of a key leave the cluster, the distribution interceptor doesn't know how to handle that key. Instead, it has to signal that to the {{PartitionHandlingInterceptor}} somehow, and PHI decides whether to return a {{null}} value or throw an {{AvailabilityException}}. > Single-key read commands and write commands are handled by throwing an {{AllOwnersLostException}} (initially an {{RpcException}}) from the distribution interceptor and catching it in {{PartitionHandlingInterceptor}}. If partitioning handling is disabled, the {{AllOwnersLostException}} is instead caught by {{StateTransferInterceptor}}, which returns the {{null}} value (for read commands) or waits for a new topology and retries (for write commands). > For multi-key read commands the distribution interceptor can't throw an exception, because that would lose the values that were retrieved successfully. For {{GetAllCommand}} we could get away with storing the values in the context, but that wouldn't work for functional commands because they transform the values on the remote node. ISPN-7884 removing the values with missing owners from the result collection, but that means values that are simply missing have to be treated differently, and {{StateTransferInterceptor}} has to iterate through the list of results again in order to remove them. > It should be simpler to move all the availability checks to the distribution interceptor, and remove the {{PartitionHandlingInterceptor}}. DI already calls some {{PartitionHandlingManager}} methods directly, in order to keep track of partially committed transactions. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7956) Investigate removing PartitionHandlingInterceptor

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-7956?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-7956: ------------------------------- Component/s: Core (was: Test Suite - Core) > Investigate removing PartitionHandlingInterceptor > ------------------------------------------------- > > Key: ISPN-7956 > URL: https://issues.jboss.org/browse/ISPN-7956 > Project: Infinispan > Issue Type: Task > Components: Core > Affects Versions: 9.1.0.Beta1 > Reporter: Dan Berindei > Assignee: Dan Berindei > > When all the owners of a key leave the cluster, the distribution interceptor doesn't know how to handle that key. Instead, it has to signal that to the {{PartitionHandlingInterceptor}} somehow, and PHI decides whether to return a {{null}} value or throw an {{AvailabilityException}}. > Single-key read commands and write commands are handled by throwing an {{AllOwnersLostException}} (initially an {{RpcException}}) from the distribution interceptor and catching it in {{PartitionHandlingInterceptor}}. If partitioning handling is disabled, the {{AllOwnersLostException}} is instead caught by {{StateTransferInterceptor}}, which returns the {{null}} value (for read commands) or waits for a new topology and retries (for write commands). > For multi-key read commands the distribution interceptor can't throw an exception, because that would lose the values that were retrieved successfully. For {{GetAllCommand}} we could get away with storing the values in the context, but that wouldn't work for functional commands because they transform the values on the remote node. ISPN-7884 removing the values with missing owners from the result collection, but that means values that are simply missing have to be treated differently, and {{StateTransferInterceptor}} has to iterate through the list of results again in order to remove them. > It should be simpler to move all the availability checks to the distribution interceptor, and remove the {{PartitionHandlingInterceptor}}. DI already calls some {{PartitionHandlingManager}} methods directly, in order to keep track of partially committed transactions. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7988) ScatteredSyncFuncTest>DistSyncFuncTest.testComputeIfAbsentFromNonOwner fails with trace logging enabled

by Dan Berindei (JIRA)

Dan Berindei created ISPN-7988: ---------------------------------- Summary: ScatteredSyncFuncTest>DistSyncFuncTest.testComputeIfAbsentFromNonOwner fails with trace logging enabled Key: ISPN-7988 URL: https://issues.jboss.org/browse/ISPN-7988 Project: Infinispan Issue Type: Bug Reporter: Dan Berindei Assignee: Radim Vansa Priority: Critical Every time I run the test I get this failure twice, with the same test parameters: {noformat} testComputeIfAbsentFromNonOwner[SCATTERED_SYNC, tx=false, numOwners=1, l1=false](org.infinispan.scattered.ScatteredSyncFuncTest) Time elapsed: 0.159 sec <<< FAILURE! java.lang.AssertionError: expected [1] but found [0] at org.testng.Assert.fail(Assert.java:94) at org.testng.Assert.failNotEquals(Assert.java:494) at org.testng.Assert.assertEquals(Assert.java:123) at org.testng.Assert.assertEquals(Assert.java:370) at org.testng.Assert.assertEquals(Assert.java:380) at org.infinispan.scattered.Utils.assertOwnershipAndNonOwnership(Utils.java:49) at org.infinispan.scattered.ScatteredSyncFuncTest.assertOwnershipAndNonOwnership(ScatteredSyncFuncTest.java:20) at org.infinispan.distribution.BaseDistFunctionalTest.assertOnAllCachesAndOwnership(BaseDistFunctionalTest.java:162) {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7988) ScatteredSyncFuncTest>DistSyncFuncTest.testComputeIfAbsentFromNonOwner fails with trace logging enabled

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-7988?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-7988: ------------------------------- Status: Open (was: New) > ScatteredSyncFuncTest>DistSyncFuncTest.testComputeIfAbsentFromNonOwner fails with trace logging enabled > ------------------------------------------------------------------------------------------------------- > > Key: ISPN-7988 > URL: https://issues.jboss.org/browse/ISPN-7988 > Project: Infinispan > Issue Type: Bug > Reporter: Dan Berindei > Assignee: Radim Vansa > Priority: Critical > Labels: testsuite_stability > > Every time I run the test I get this failure twice, with the same test parameters: > {noformat} > testComputeIfAbsentFromNonOwner[SCATTERED_SYNC, tx=false, numOwners=1, l1=false](org.infinispan.scattered.ScatteredSyncFuncTest) Time elapsed: 0.159 sec <<< FAILURE! > java.lang.AssertionError: expected [1] but found [0] > at org.testng.Assert.fail(Assert.java:94) > at org.testng.Assert.failNotEquals(Assert.java:494) > at org.testng.Assert.assertEquals(Assert.java:123) > at org.testng.Assert.assertEquals(Assert.java:370) > at org.testng.Assert.assertEquals(Assert.java:380) > at org.infinispan.scattered.Utils.assertOwnershipAndNonOwnership(Utils.java:49) > at org.infinispan.scattered.ScatteredSyncFuncTest.assertOwnershipAndNonOwnership(ScatteredSyncFuncTest.java:20) > at org.infinispan.distribution.BaseDistFunctionalTest.assertOnAllCachesAndOwnership(BaseDistFunctionalTest.java:162) > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7982) Ickle purely negative fulltext subqueries cause empty results

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-7982?page=com.atlassian.jira.plugin.... ] Adrian Nistor reassigned ISPN-7982: ----------------------------------- Assignee: Adrian Nistor > Ickle purely negative fulltext subqueries cause empty results > ------------------------------------------------------------- > > Key: ISPN-7982 > URL: https://issues.jboss.org/browse/ISPN-7982 > Project: Infinispan > Issue Type: Bug > Components: Embedded Querying > Affects Versions: 9.0.0.Final > Reporter: Gustavo Fernandes > Assignee: Adrian Nistor > Fix For: 9.1.0.Final > > > When using parethesis in an Ickle full text predicate, it can generate subqueries that are pure negative, e.g. > {{from IspnEvent where (tags : ('tagA' and (not 'a0')))}} > In Lucene, the query > {{+tags:taga +(-tags:a0)}} > is different from > {{+tags:taga -tags:a0}} > The latter works as expected, but the former brings empty results since Lucene does no support purely negative subqueries. In order for the former query to work, it needs to add all documents as another term to the subquery, for e.g. {{+tags:taga +(\*:\* -tags:a0)}}. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7987) Object-filter is missing from javadoc

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-7987?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-7987: -------------------------------- Summary: Object-filter is missing from javadoc (was: Object-filter in missing from javadoc) > Object-filter is missing from javadoc > ------------------------------------- > > Key: ISPN-7987 > URL: https://issues.jboss.org/browse/ISPN-7987 > Project: Infinispan > Issue Type: Bug > Components: Build process > Affects Versions: 9.0.0.Final > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 9.1.0.CR1, 9.0.4.Final > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues June 2017