[JBoss JIRA] (ISPN-4860) RemoteStore test doesn't pass unless bumping up to version 2.0
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4860?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4860:
-----------------------------------------------
Vojtech Juranek <vjuranek(a)redhat.com> changed the Status of [bug 1163794|https://bugzilla.redhat.com/show_bug.cgi?id=1163794] from ON_QA to VERIFIED
> RemoteStore test doesn't pass unless bumping up to version 2.0
> --------------------------------------------------------------
>
> Key: ISPN-4860
> URL: https://issues.jboss.org/browse/ISPN-4860
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Server
> Affects Versions: 7.0.0.CR1
> Reporter: William Burns
> Assignee: Galder Zamarreño
> Priority: Critical
> Fix For: 7.0.0.Final
>
>
> Recent changes to hot rod protocol for async operations I had to bump the version of the REST store to the latest version.
> https://github.com/infinispan/infinispan/commit/84c0af6ca965b7eedeb04ef1e...
> However this should have worked before. Below are the failiures met if reverting the commit.
> {code}
> testLoadAndStoreMarshalledValues(org.infinispan.persistence.remote.RemoteStoreRawValuesTest) Time elapsed: 0.048 sec <<< FAILURE!
> org.infinispan.client.hotrod.exceptions.InvalidResponseException:: Invalid magic number. Expected 0xa1 and received 0x0
> at org.infinispan.client.hotrod.impl.protocol.Codec10.readHeader(Codec10.java:77)
> at org.infinispan.client.hotrod.impl.operations.HotRodOperation.readHeaderAndValidate(HotRodOperation.java:56)
> at org.infinispan.client.hotrod.impl.operations.AbstractKeyOperation.sendKeyOperation(AbstractKeyOperation.java:53)
> at org.infinispan.client.hotrod.impl.operations.RemoveOperation.executeOperation(RemoveOperation.java:28)
> at org.infinispan.client.hotrod.impl.operations.RemoveOperation.executeOperation(RemoveOperation.java:18)
> at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:50)
> at org.infinispan.client.hotrod.impl.RemoteCacheImpl.remove(RemoteCacheImpl.java:452)
> at org.infinispan.persistence.remote.RemoteStore.delete(RemoteStore.java:182)
> at org.infinispan.persistence.BaseStoreTest.testLoadAndStoreMarshalledValues(BaseStoreTest.java:479)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
> 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:262)
> 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:744)
> testLoadAndStoreMarshalledValues(org.infinispan.persistence.remote.RemoteStoreTest) Time elapsed: 0.004 sec <<< FAILURE!
> org.infinispan.client.hotrod.exceptions.InvalidResponseException:: Invalid magic number. Expected 0xa1 and received 0x0
> at org.infinispan.client.hotrod.impl.protocol.Codec10.readHeader(Codec10.java:77)
> at org.infinispan.client.hotrod.impl.operations.HotRodOperation.readHeaderAndValidate(HotRodOperation.java:56)
> at org.infinispan.client.hotrod.impl.operations.AbstractKeyOperation.sendKeyOperation(AbstractKeyOperation.java:53)
> at org.infinispan.client.hotrod.impl.operations.RemoveOperation.executeOperation(RemoveOperation.java:28)
> at org.infinispan.client.hotrod.impl.operations.RemoveOperation.executeOperation(RemoveOperation.java:18)
> at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:50)
> at org.infinispan.client.hotrod.impl.RemoteCacheImpl.remove(RemoteCacheImpl.java:452)
> at org.infinispan.persistence.remote.RemoteStore.delete(RemoteStore.java:182)
> at org.infinispan.persistence.BaseStoreTest.testLoadAndStoreMarshalledValues(BaseStoreTest.java:479)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
> 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:262)
> 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:744)
> testStoreAndRemove(org.infinispan.persistence.remote.RemoteStoreRawValuesTest) Time elapsed: 0.005 sec <<< FAILURE!
> org.infinispan.client.hotrod.exceptions.InvalidResponseException:: Invalid magic number. Expected 0xa1 and received 0x5
> at org.infinispan.client.hotrod.impl.protocol.Codec10.readHeader(Codec10.java:77)
> at org.infinispan.client.hotrod.impl.operations.HotRodOperation.readHeaderAndValidate(HotRodOperation.java:56)
> at org.infinispan.client.hotrod.impl.operations.AbstractKeyOperation.sendKeyOperation(AbstractKeyOperation.java:53)
> at org.infinispan.client.hotrod.impl.operations.RemoveOperation.executeOperation(RemoveOperation.java:28)
> at org.infinispan.client.hotrod.impl.operations.RemoveOperation.executeOperation(RemoveOperation.java:18)
> at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:50)
> at org.infinispan.client.hotrod.impl.RemoteCacheImpl.remove(RemoteCacheImpl.java:452)
> at org.infinispan.persistence.remote.RemoteStore.delete(RemoteStore.java:182)
> at org.infinispan.persistence.BaseStoreTest.testStoreAndRemove(BaseStoreTest.java:374)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
> 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:262)
> 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:744)
> testStoreAndRemove(org.infinispan.persistence.remote.RemoteStoreTest) Time elapsed: 0.007 sec <<< FAILURE!
> org.infinispan.client.hotrod.exceptions.InvalidResponseException:: Invalid magic number. Expected 0xa1 and received 0x1a
> at org.infinispan.client.hotrod.impl.protocol.Codec10.readHeader(Codec10.java:77)
> at org.infinispan.client.hotrod.impl.operations.HotRodOperation.readHeaderAndValidate(HotRodOperation.java:56)
> at org.infinispan.client.hotrod.impl.operations.AbstractKeyOperation.sendKeyOperation(AbstractKeyOperation.java:53)
> at org.infinispan.client.hotrod.impl.operations.RemoveOperation.executeOperation(RemoveOperation.java:28)
> at org.infinispan.client.hotrod.impl.operations.RemoveOperation.executeOperation(RemoveOperation.java:18)
> at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:50)
> at org.infinispan.client.hotrod.impl.RemoteCacheImpl.remove(RemoteCacheImpl.java:452)
> at org.infinispan.persistence.remote.RemoteStore.delete(RemoteStore.java:182)
> at org.infinispan.persistence.BaseStoreTest.testStoreAndRemove(BaseStoreTest.java:374)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
> 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:262)
> 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:744)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (ISPN-5103) Inefficient index updates cause high cost merges and increase overall latency
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-5103?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero commented on ISPN-5103:
---------------------------------------
{quote}Same cache with multiple entity types: that's a non-issue, since obviously there's no id collision in this case{quote}
Right, as the transformation to term from ID type is required to be biunique.
{quote}Different caches with the same index: this scenario happens when different caches share the same index, for ex:{quote}
I'm actually thinking this case wouldn't work, because when searching an index and loading results, we have no way to identify if the matching ID needs to be reincarnated into a key for current Cache (the one on which the query is executed) or if ID was relating to a different Cache. Sharing indexes across caches is something we should discourage, or leave for the very savvy user only.
> Inefficient index updates cause high cost merges and increase overall latency
> -----------------------------------------------------------------------------
>
> Key: ISPN-5103
> URL: https://issues.jboss.org/browse/ISPN-5103
> Project: Infinispan
> Issue Type: Enhancement
> Components: Embedded Querying
> Affects Versions: 7.0.2.Final, 7.1.0.Alpha1
> Reporter: Gustavo Fernandes
>
> Currently every change to the index is done Lucene-wise combining two operations:
> * Delete by query, using a boolean query on the id plus the entity class
> * Add
>
> Under high load, specially during merges those numerous deletes provoke very long delays causing high latency.
> We should instead use a simple Lucene Update to add/change documents, since internally it translates to a Delete by term plus an Add operation, and delete by terms are extremely efficient in Lucene.
> Some local tests showed average latency of updating the index using this strategy to drop 4 times, both for the SYNC and ASYNC backends
> With relation to sharing the index between entities, which was the original motivation of the Delete by query plus add strategy, we have two scenarios:
> * Same cache with multiple entity types: that's a non-issue, since obviously there's no id collision in this case
> * Different caches with the same index: this scenario happens when different caches shares the same index, for ex:
> {code}
> @Indexed(indexName=common)
> public class Country { ... }
> @Indexed(indexName=common)
> public class Currency { ... }
> cm.getCache("currencies").put(1, new Currency(...))
> cm.getCache("countries").put(1, new Country(...))
> {code}
> This would require a delete by query in order to persist both a Country and a Currency with id=1.
> It would also require setting "default.exclusive_index_use", "false", with the associated cost of having to reopen the IndexWriter on every operation.
> Given the performance gain of doing a simple Update is considerable, we should make the corner case supported by extra configuration or alternatively, generate a unique @ProvidedId, including the entity class or the cache name that work for all cases described above.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (ISPN-5122) Protostream's code generator does not use the proper classloader and does not work in OSGI
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-5122?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-5122:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
Integrated in master.
> Protostream's code generator does not use the proper classloader and does not work in OSGI
> ------------------------------------------------------------------------------------------
>
> Key: ISPN-5122
> URL: https://issues.jboss.org/browse/ISPN-5122
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Querying
> Reporter: Adrian Nistor
> Assignee: Adrian Nistor
> Fix For: 7.1.0.Beta1
>
>
> {quote}
> Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.888 sec <<< FAILURE! - in org.infinispan.server.test.client.hotrod.osgi.RemoteCacheOsgiIT
> testAttributeQuery(org.infinispan.server.test.client.hotrod.osgi.RemoteCacheOsgiIT) Time elapsed: 0.122 sec <<< ERROR!
> infinispan.javassist.NotFoundException: org.infinispan.protostream.EnumMarshaller
> at infinispan.javassist.ClassPool.get(ClassPool.java:450)
> at infinispan.javassist.ClassPool.getCtClass(ClassPool.java:515)
> at org.infinispan.protostream.annotations.impl.MarshallerCodeGenerator.<init>(MarshallerCodeGenerator.java:80)
> at org.infinispan.protostream.annotations.impl.ProtoSchemaGenerator.generateMarshallers(ProtoSchemaGenerator.java:134)
> at org.infinispan.protostream.annotations.impl.ProtoSchemaGenerator.generateAndRegister(ProtoSchemaGenerator.java:106)
> at org.infinispan.protostream.annotations.ProtoSchemaBuilder.build(ProtoSchemaBuilder.java:64)
> at org.infinispan.server.test.client.hotrod.osgi.RemoteCacheOsgiIT.testAttributeQuery(RemoteCacheOsgiIT.java:138)
> Results :
> Tests in error:
> RemoteCacheOsgiIT.testAttributeQuery:138 » NotFound org.infinispan.protostream...
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (ISPN-5122) Protostream's code generator does not use the proper classloader and does not work in OSGI
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-5122?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-5122:
--------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/protostream/pull/16
> Protostream's code generator does not use the proper classloader and does not work in OSGI
> ------------------------------------------------------------------------------------------
>
> Key: ISPN-5122
> URL: https://issues.jboss.org/browse/ISPN-5122
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Querying
> Reporter: Adrian Nistor
> Assignee: Adrian Nistor
> Fix For: 7.1.0.Beta1
>
>
> {quote}
> Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.888 sec <<< FAILURE! - in org.infinispan.server.test.client.hotrod.osgi.RemoteCacheOsgiIT
> testAttributeQuery(org.infinispan.server.test.client.hotrod.osgi.RemoteCacheOsgiIT) Time elapsed: 0.122 sec <<< ERROR!
> infinispan.javassist.NotFoundException: org.infinispan.protostream.EnumMarshaller
> at infinispan.javassist.ClassPool.get(ClassPool.java:450)
> at infinispan.javassist.ClassPool.getCtClass(ClassPool.java:515)
> at org.infinispan.protostream.annotations.impl.MarshallerCodeGenerator.<init>(MarshallerCodeGenerator.java:80)
> at org.infinispan.protostream.annotations.impl.ProtoSchemaGenerator.generateMarshallers(ProtoSchemaGenerator.java:134)
> at org.infinispan.protostream.annotations.impl.ProtoSchemaGenerator.generateAndRegister(ProtoSchemaGenerator.java:106)
> at org.infinispan.protostream.annotations.ProtoSchemaBuilder.build(ProtoSchemaBuilder.java:64)
> at org.infinispan.server.test.client.hotrod.osgi.RemoteCacheOsgiIT.testAttributeQuery(RemoteCacheOsgiIT.java:138)
> Results :
> Tests in error:
> RemoteCacheOsgiIT.testAttributeQuery:138 » NotFound org.infinispan.protostream...
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (ISPN-5060) PartitionHandling: remove unavailable mode
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-5060?page=com.atlassian.jira.plugin.... ]
Work on ISPN-5060 started by Dan Berindei.
------------------------------------------
> PartitionHandling: remove unavailable mode
> ------------------------------------------
>
> Key: ISPN-5060
> URL: https://issues.jboss.org/browse/ISPN-5060
> Project: Infinispan
> Issue Type: Enhancement
> Components: Core
> Affects Versions: 7.0.2.Final, 7.1.0.Alpha1
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Critical
> Fix For: 7.1.0.Final
>
>
> The Unavailable mode name is misleading, because some keys are available, just like in Degraded mode.
> The only difference between Degraded and Unavailable is that with Degraded the cluster might recover without manual intervention. The administrator still has to know a lot more details in order to decide whether manual intervention is needed or not. So it would be less confusing if gracefully shutting down {{numOwners}} nodes in quick succession would leave the cache in Degraded mode instead of Unavailable.
> Instead of removing the Unavailable mode completely, we could also change it to deny access to all the keys and allow the administrator to use it. E.g. if we had an operation to dump the cache into a shared store and another to load the cache from a shared store, the administrator could force the cache into Unavailable mode while dumping/loading the cache.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (ISPN-5122) Protostream's code generator does not use the proper classloader and does not work in OSGI
by Adrian Nistor (JIRA)
Adrian Nistor created ISPN-5122:
-----------------------------------
Summary: Protostream's code generator does not use the proper classloader and does not work in OSGI
Key: ISPN-5122
URL: https://issues.jboss.org/browse/ISPN-5122
Project: Infinispan
Issue Type: Bug
Components: Remote Querying
Reporter: Adrian Nistor
Assignee: Adrian Nistor
Fix For: 7.1.0.Beta1
{quote}
Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.888 sec <<< FAILURE! - in org.infinispan.server.test.client.hotrod.osgi.RemoteCacheOsgiIT
testAttributeQuery(org.infinispan.server.test.client.hotrod.osgi.RemoteCacheOsgiIT) Time elapsed: 0.122 sec <<< ERROR!
infinispan.javassist.NotFoundException: org.infinispan.protostream.EnumMarshaller
at infinispan.javassist.ClassPool.get(ClassPool.java:450)
at infinispan.javassist.ClassPool.getCtClass(ClassPool.java:515)
at org.infinispan.protostream.annotations.impl.MarshallerCodeGenerator.<init>(MarshallerCodeGenerator.java:80)
at org.infinispan.protostream.annotations.impl.ProtoSchemaGenerator.generateMarshallers(ProtoSchemaGenerator.java:134)
at org.infinispan.protostream.annotations.impl.ProtoSchemaGenerator.generateAndRegister(ProtoSchemaGenerator.java:106)
at org.infinispan.protostream.annotations.ProtoSchemaBuilder.build(ProtoSchemaBuilder.java:64)
at org.infinispan.server.test.client.hotrod.osgi.RemoteCacheOsgiIT.testAttributeQuery(RemoteCacheOsgiIT.java:138)
Results :
Tests in error:
RemoteCacheOsgiIT.testAttributeQuery:138 » NotFound org.infinispan.protostream...
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (ISPN-5122) Protostream's code generator does not use the proper classloader and does not work in OSGI
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-5122?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-5122:
--------------------------------
Status: Open (was: New)
> Protostream's code generator does not use the proper classloader and does not work in OSGI
> ------------------------------------------------------------------------------------------
>
> Key: ISPN-5122
> URL: https://issues.jboss.org/browse/ISPN-5122
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Querying
> Reporter: Adrian Nistor
> Assignee: Adrian Nistor
> Fix For: 7.1.0.Beta1
>
>
> {quote}
> Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.888 sec <<< FAILURE! - in org.infinispan.server.test.client.hotrod.osgi.RemoteCacheOsgiIT
> testAttributeQuery(org.infinispan.server.test.client.hotrod.osgi.RemoteCacheOsgiIT) Time elapsed: 0.122 sec <<< ERROR!
> infinispan.javassist.NotFoundException: org.infinispan.protostream.EnumMarshaller
> at infinispan.javassist.ClassPool.get(ClassPool.java:450)
> at infinispan.javassist.ClassPool.getCtClass(ClassPool.java:515)
> at org.infinispan.protostream.annotations.impl.MarshallerCodeGenerator.<init>(MarshallerCodeGenerator.java:80)
> at org.infinispan.protostream.annotations.impl.ProtoSchemaGenerator.generateMarshallers(ProtoSchemaGenerator.java:134)
> at org.infinispan.protostream.annotations.impl.ProtoSchemaGenerator.generateAndRegister(ProtoSchemaGenerator.java:106)
> at org.infinispan.protostream.annotations.ProtoSchemaBuilder.build(ProtoSchemaBuilder.java:64)
> at org.infinispan.server.test.client.hotrod.osgi.RemoteCacheOsgiIT.testAttributeQuery(RemoteCacheOsgiIT.java:138)
> Results :
> Tests in error:
> RemoteCacheOsgiIT.testAttributeQuery:138 » NotFound org.infinispan.protostream...
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (ISPN-4867) HotRodRemoteCacheIT(localmode-udp).testCustomEvents random failures
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4867?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4867:
-----------------------------------------------
Vojtech Juranek <vjuranek(a)redhat.com> changed the Status of [bug 1156310|https://bugzilla.redhat.com/show_bug.cgi?id=1156310] from ON_QA to VERIFIED
> HotRodRemoteCacheIT(localmode-udp).testCustomEvents random failures
> -------------------------------------------------------------------
>
> Key: ISPN-4867
> URL: https://issues.jboss.org/browse/ISPN-4867
> Project: Infinispan
> Issue Type: Bug
> Components: Server, Test Suite - Server
> Affects Versions: 7.0.0.CR1
> Reporter: Dan Berindei
> Assignee: Galder Zamarreño
> Priority: Blocker
> Labels: testsuite_stability
> Fix For: 7.0.0.Final
>
>
> {noformat}
> org.infinispan.client.hotrod.exceptions.HotRodClientException: org.infinispan.commons.CacheException: java.lang.NoClassDefFoundError: org/infinispan/server/test/client/hotrod/HotRodCustomMarshallerEventIT$Id
> at org.infinispan.client.hotrod.impl.protocol.Codec20.checkForErrorsInResponseStatus(Codec20.java:284)
> at org.infinispan.client.hotrod.impl.protocol.Codec20.readPartialHeader(Codec20.java:86)
> at org.infinispan.client.hotrod.impl.protocol.Codec20.readHeader(Codec20.java:72)
> at org.infinispan.client.hotrod.impl.operations.HotRodOperation.readHeaderAndValidate(HotRodOperation.java:56)
> at org.infinispan.client.hotrod.impl.operations.AbstractKeyValueOperation.sendPutOperation(AbstractKeyValueOperation.java:50)
> at org.infinispan.client.hotrod.impl.operations.PutOperation.executeOperation(PutOperation.java:30)
> at org.infinispan.client.hotrod.impl.operations.PutOperation.executeOperation(PutOperation.java:19)
> at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:50)
> at org.infinispan.client.hotrod.impl.RemoteCacheImpl.put(RemoteCacheImpl.java:237)
> at org.infinispan.client.hotrod.impl.RemoteCacheSupport.put(RemoteCacheSupport.java:79)
> at org.infinispan.server.test.client.hotrod.AbstractRemoteCacheIT.testCustomEvents(AbstractRemoteCacheIT.java:855)
> {noformat}
> Tests {{testCustomEventsDynamic}}, {{testEventFilteringDynamic}}, {{testEventFilteringStatic}} fail with the same error message.
> Failing since http://ci.infinispan.org/viewLog.html?buildTypeId=bt8&buildId=12713
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (ISPN-5103) Inefficient index updates cause high cost merges and increase overall latency
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-5103?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero updated ISPN-5103:
----------------------------------
Description:
Currently every change to the index is done Lucene-wise combining two operations:
* Delete by query, using a boolean query on the id plus the entity class
* Add
Under high load, specially during merges those numerous deletes provoke very long delays causing high latency.
We should instead use a simple Lucene Update to add/change documents, since internally it translates to a Delete by term plus an Add operation, and delete by terms are extremely efficient in Lucene.
Some local tests showed average latency of updating the index using this strategy to drop 4 times, both for the SYNC and ASYNC backends
With relation to sharing the index between entities, which was the original motivation of the Delete by query plus add strategy, we have two scenarios:
* Same cache with multiple entity types: that's a non-issue, since obviously there's no id collision in this case
* Different caches with the same index: this scenario happens when different caches shares the same index, for ex:
{code}
@Indexed(indexName=common)
public class Country { ... }
@Indexed(indexName=common)
public class Currency { ... }
cm.getCache("currencies").put(1, new Currency(...))
cm.getCache("countries").put(1, new Country(...))
{code}
This would require a delete by query in order to persist both a Country and a Currency with id=1.
It would also require setting "default.exclusive_index_use", "false", with the associated cost of having to reopen the IndexWriter on every operation.
Given the performance gain of doing a simple Update is considerable, we should make the corner case supported by extra configuration or alternatively, generate a unique @ProvidedId, including the entity class or the cache name that work for all cases described above.
was:
Currently every change to the index is done Lucene-wise combining two operations:
* Delete by query, using a boolean query on the id plus the entity class
* Add
Under high load, specially during merges those numerous deletes provoke very long delays causing high latency.
We should instead use a simple Lucene Update to add/change documents, since internally it translates to a Delete by term plus an Add operation, and delete by terms are extremely efficient in Lucene.
Some local tests showed average latency of updating the index using this strategy to drop 4 times, both for the SYNC and ASYNC backends
With relation to sharing the index between entities, which was the original motivation of the Delete by query plus add strategy, we have two scenarios:
* Same cache with muliple entity types: that's a non-issue, since obviously there's no id colision in this case
* Different caches with the same index: this scenario happens when different caches shares the same index, for ex:
{code}
@Indexed(indeName=common)
public class Country { ... }
@Indexed(indeName=common)
public class Currency { ... }
cm.getCache("currencies").put(1, new Currency(...))
cm.getCache("countries").put(1, new Country(...))
{code}
This would require a delete by query in order to persist both a Country and a Currency with id=1.
It would also require setting "default.exclusive_index_use", "false", with the associated cost of having to reopen the IndexWriter on every operation.
Given the performance gain of doing a simple Update is considerable, we should make the corner case supported by extra configuration or alternatively, generate a unique @ProvidedId, including the entity class or the cache name that work for all cases described above.
> Inefficient index updates cause high cost merges and increase overall latency
> -----------------------------------------------------------------------------
>
> Key: ISPN-5103
> URL: https://issues.jboss.org/browse/ISPN-5103
> Project: Infinispan
> Issue Type: Enhancement
> Components: Embedded Querying
> Affects Versions: 7.0.2.Final, 7.1.0.Alpha1
> Reporter: Gustavo Fernandes
>
> Currently every change to the index is done Lucene-wise combining two operations:
> * Delete by query, using a boolean query on the id plus the entity class
> * Add
>
> Under high load, specially during merges those numerous deletes provoke very long delays causing high latency.
> We should instead use a simple Lucene Update to add/change documents, since internally it translates to a Delete by term plus an Add operation, and delete by terms are extremely efficient in Lucene.
> Some local tests showed average latency of updating the index using this strategy to drop 4 times, both for the SYNC and ASYNC backends
> With relation to sharing the index between entities, which was the original motivation of the Delete by query plus add strategy, we have two scenarios:
> * Same cache with multiple entity types: that's a non-issue, since obviously there's no id collision in this case
> * Different caches with the same index: this scenario happens when different caches shares the same index, for ex:
> {code}
> @Indexed(indexName=common)
> public class Country { ... }
> @Indexed(indexName=common)
> public class Currency { ... }
> cm.getCache("currencies").put(1, new Currency(...))
> cm.getCache("countries").put(1, new Country(...))
> {code}
> This would require a delete by query in order to persist both a Country and a Currency with id=1.
> It would also require setting "default.exclusive_index_use", "false", with the associated cost of having to reopen the IndexWriter on every operation.
> Given the performance gain of doing a simple Update is considerable, we should make the corner case supported by extra configuration or alternatively, generate a unique @ProvidedId, including the entity class or the cache name that work for all cases described above.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months