[JBoss JIRA] (ISPN-3649) RemoteStoreRawValuesTest.testLoadAndStoreWithLifespanAndIdle && RemoteStoreTest.testLoadAndStoreWithIdle fails periodically on Windows2008R2
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3649?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3649:
-----------------------------------------------
Paul Ferraro <paul.ferraro(a)redhat.com> changed the Status of [bug 1028339|https://bugzilla.redhat.com/show_bug.cgi?id=1028339] from NEW to CLOSED
> RemoteStoreRawValuesTest.testLoadAndStoreWithLifespanAndIdle && RemoteStoreTest.testLoadAndStoreWithIdle fails periodically on Windows2008R2
> --------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-3649
> URL: https://issues.jboss.org/browse/ISPN-3649
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Loaders and Stores, Test Suite - Core
> Affects Versions: 6.0.0.CR1, 7.0.0.Alpha1, 7.0.0.Alpha2
> Environment: Windows 2008R2 && JDK6
> Reporter: Anna Manukyan
> Assignee: Dan Berindei
> Labels: testsuite_stability
>
> Tests fail randomly on Windows 2008R2 machine
> RemoteStoreRawValuesTest.testLoadAndStoreWithLifespanAndIdle
> The failure error is:
> {code}
> java.lang.AssertionError
> at org.infinispan.persistence.remote.RemoteStoreRawValuesTest.assertEventuallyExpires(RemoteStoreRawValuesTest.java:91)
> at org.infinispan.persistence.BaseStoreTest.testLoadAndStoreWithLifespanAndIdle(BaseStoreTest.java:211)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:715)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:907)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1237)
> 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:334)
> at org.testng.SuiteRunner.access$000(SuiteRunner.java:37)
> at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:368)
> at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
> at java.lang.Thread.run(Thread.java:662)
> {code}
> RemoteStoreTest.testLoadAndStoreWithIdle
> {code}
> java.lang.AssertionError
> at org.infinispan.persistence.remote.RemoteStoreTest.assertEventuallyExpires(RemoteStoreTest.java:89)
> at org.infinispan.persistence.BaseStoreTest.testLoadAndStoreWithIdle(BaseStoreTest.java:206)
> 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:80)
> 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:334)
> at org.testng.SuiteRunner.access$000(SuiteRunner.java:37)
> at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:368)
> 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.1#6329)
10 years, 6 months
[JBoss JIRA] (ISPN-4650) MassIndexer should not use UpdateDocument when adding to Lucene
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-4650?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero commented on ISPN-4650:
---------------------------------------
{quote} I'd like to explore a 3rd alternative besides using auto switch and queues, which is relying on UpdateExtWorkDelegate. Some local tests demonstrated this kind of delegate to be closer performance wise to the AddWorkDelegate. I'm aware the implications of its usage (being recommended if keys are unique in an index), and I think infinispan ticks the boxes, doesn't it?{quote}
It's not too uncommon for people to share a same index for different types. We would need to make sure that such configurations are not possible; maybe that's a clever logic which could be applied by the automatic configuration approach you've been working on?
But if the user is allowed to change all the configuration options as he can do today, this is unfortunately not a safe assumption.
An alternative could be to always perform both the ADD and the REMOVE operations, but allowing IndexWriter commits and IndexReader refreshes to skip the flush on the delete operations: when Query returns a List of matches, it's supposed going to ignore the matches which it won't load.
This doesn't work when projections are being used (But we can know when they are been used) and might break some pagination operations: in Search (ORM) the pagination is compensated for by adding some entries from the next page, but the exact indexes of page boundaries might be inaccurate.
> MassIndexer should not use UpdateDocument when adding to Lucene
> ---------------------------------------------------------------
>
> Key: ISPN-4650
> URL: https://issues.jboss.org/browse/ISPN-4650
> Project: Infinispan
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Embedded Querying
> Affects Versions: 7.0.0.Beta1
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
> Fix For: 7.0.0.Beta2
>
>
> The MassIndexer currently causes a Delete plus and Add operation to hibernate search backend.
> Lucene buffers those deletes queries and during merge it tries to 'apply' those deletes wasting a massive amount of time doing seeks and queries unnecessarily.
> Since the mass indexer wipes the index at the beginning, it should simply issue an add operation (or at least rely on Lucene atomic IndexWriter.updateDocument). Performance wise this make a huge difference:
> * indexing 50k documents brings down the indexing time from 195s to 33s
> * indexing 200k documents brings down the indexing time from 600s to 55s
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 6 months
[JBoss JIRA] (ISPN-2771) WriteSkewTest.testWriteSkewWithOnlyPut fails randomly
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-2771?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-2771:
-----------------------------------------------
Paul Ferraro <paul.ferraro(a)redhat.com> changed the Status of [bug 921491|https://bugzilla.redhat.com/show_bug.cgi?id=921491] from NEW to CLOSED
> WriteSkewTest.testWriteSkewWithOnlyPut fails randomly
> -----------------------------------------------------
>
> Key: ISPN-2771
> URL: https://issues.jboss.org/browse/ISPN-2771
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Test Suite - Core, Transactions
> Affects Versions: 5.2.0.CR3
> Reporter: Adrian Nistor
> Assignee: Pedro Ruivo
> Fix For: 6.0.0.Alpha2, 6.0.0.CR1
>
> Attachments: WriteSkewTest.zip
>
>
> {noformat}
> org.infinispan.api.mvcc.repeatable_read.WriteSkewTest:testWriteSkewWithOnlyPut
> org.infinispan.transaction.WriteSkewException: Detected write skew.
> java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:222)
> at java.util.concurrent.FutureTask.get(FutureTask.java:83)
> at org.infinispan.api.mvcc.repeatable_read.WriteSkewTest.testWriteSkewWithOnlyPut(WriteSkewTest.java:315)
> 22 lines not shown
> Caused by Detected write skew.
> org.infinispan.container.entries.RepeatableReadEntry.performLocalWriteSkewCheck(RepeatableReadEntry.java:68)
> at org.infinispan.container.entries.RepeatableReadEntry.copyForUpdate(RepeatableReadEntry.java:52)
> at org.infinispan.container.EntryFactoryImpl.wrapEntryForPut(EntryFactoryImpl.java:170)
> at org.infinispan.interceptors.EntryWrappingInterceptor.visitPutKeyValueCommand(EntryWrappingInterceptor.java:164)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:77)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.locking.OptimisticLockingInterceptor.visitPutKeyValueCommand(OptimisticLockingInterceptor.java:142)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:77)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:132)
> at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:62)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:77)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:251)
> at org.infinispan.interceptors.TxInterceptor.visitPutKeyValueCommand(TxInterceptor.java:191)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:77)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:128)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:92)
> at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:62)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:77)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:343)
> at org.infinispan.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1162)
> at org.infinispan.CacheImpl.putInternal(CacheImpl.java:760)
> at org.infinispan.CacheImpl.put(CacheImpl.java:754)
> at org.infinispan.CacheImpl.put(CacheImpl.java:748)
> at org.infinispan.CacheSupport.put(CacheSupport.java:53)
> at org.infinispan.api.mvcc.repeatable_read.WriteSkewTest$EntryWriter.call(WriteSkewTest.java:433)
> at org.infinispan.api.mvcc.repeatable_read.WriteSkewTest$EntryWriter.call(WriteSkewTest.java:418)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> 1 lines not shown
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 6 months
[JBoss JIRA] (ISPN-2659) org.infinispan.statetransfer.StateTransferLargeObjectTest.testForFailure fails randomly
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-2659?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-2659:
-----------------------------------------------
Paul Ferraro <paul.ferraro(a)redhat.com> changed the Status of [bug 921539|https://bugzilla.redhat.com/show_bug.cgi?id=921539] from NEW to CLOSED
> org.infinispan.statetransfer.StateTransferLargeObjectTest.testForFailure fails randomly
> ----------------------------------------------------------------------------------------
>
> Key: ISPN-2659
> URL: https://issues.jboss.org/browse/ISPN-2659
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 5.2.0.Beta6
> Reporter: Anna Manukyan
> Assignee: Adrian Nistor
> Labels: testsuite_stability
> Fix For: 5.2.2.Final, 5.3.0.Alpha1
>
>
> org.infinispan.statetransfer.StateTransferLargeObjectTest.testForFailure fails randomly on RHEL environment for Opend JDK7 & JDK7.
> The error message is:
> {code}
> Error Message
> expected object to not be null
> Stacktrace
> java.lang.AssertionError: expected object to not be null
> at org.testng.Assert.fail(Assert.java:89)
> at org.testng.Assert.assertNotNull(Assert.java:399)
> at org.testng.Assert.assertNotNull(Assert.java:384)
> at org.infinispan.statetransfer.StateTransferLargeObjectTest.assertValue(StateTransferLargeObjectTest.java:145)
> at org.infinispan.statetransfer.StateTransferLargeObjectTest.testForFailure(StateTransferLargeObjectTest.java:122)
> 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:601)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:715)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:907)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1237)
> 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:334)
> at org.testng.SuiteRunner.access$000(SuiteRunner.java:37)
> at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:368)
> at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 6 months
[JBoss JIRA] (ISPN-4650) MassIndexer should not use UpdateDocument when adding to Lucene
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-4650?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero updated ISPN-4650:
----------------------------------
Status: Open (was: Pull Request Sent)
> MassIndexer should not use UpdateDocument when adding to Lucene
> ---------------------------------------------------------------
>
> Key: ISPN-4650
> URL: https://issues.jboss.org/browse/ISPN-4650
> Project: Infinispan
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Embedded Querying
> Affects Versions: 7.0.0.Beta1
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
> Fix For: 7.0.0.Beta2
>
>
> The MassIndexer currently causes a Delete plus and Add operation to hibernate search backend.
> Lucene buffers those deletes queries and during merge it tries to 'apply' those deletes wasting a massive amount of time doing seeks and queries unnecessarily.
> Since the mass indexer wipes the index at the beginning, it should simply issue an add operation (or at least rely on Lucene atomic IndexWriter.updateDocument). Performance wise this make a huge difference:
> * indexing 50k documents brings down the indexing time from 195s to 33s
> * indexing 200k documents brings down the indexing time from 600s to 55s
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 6 months
[JBoss JIRA] (ISPN-4573) Unable to serialize List<LuceneWork>
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-4573?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero resolved ISPN-4573.
-----------------------------------
Resolution: Done
Resolved by ISPN-4636
> Unable to serialize List<LuceneWork>
> ------------------------------------
>
> Key: ISPN-4573
> URL: https://issues.jboss.org/browse/ISPN-4573
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Embedded Querying
> Affects Versions: 7.0.0.Alpha5
> Reporter: Radim Vansa
> Assignee: Sanne Grinovero
> Priority: Critical
> Fix For: 7.0.0.Beta2
>
>
> When I try to fill distributed cache with indexing enabled concurrently from multiple threads, I get
> {code}
> org.hibernate.search.exception.SearchException: HSEARCH000083: Unable to serialize List<LuceneWork>
> at org.hibernate.search.indexes.serialization.impl.LuceneWorkSerializerImpl.toSerializedModel(LuceneWorkSerializerImpl.java:92)
> ...
> Caused by: java.lang.ArrayIndexOutOfBoundsException: 6
> at java.util.ArrayList.add(ArrayList.java:412)
> at org.hibernate.search.indexes.serialization.avro.impl.AvroSerializer.addFieldWithStringData(AvroSerializer.java:258)
> at org.hibernate.search.indexes.serialization.impl.LuceneWorkSerializerImpl.buildDocument(LuceneWorkSerializerImpl.java:174)
> at org.hibernate.search.indexes.serialization.impl.LuceneWorkSerializerImpl.toSerializedModel(LuceneWorkSerializerImpl.java:80)
> {code}
> There are multiple different exceptions as cause, but the reason is one: {{AvroSerializer}} is not thead-safe. {{AvroSerializerProvider}} returns always the same instance, and so does {{InfinispanIndexManager}} (or rather {{DirectoryBasedIndexManager}}) return the same instance of {{LuceneWorkSerializerImpl}} wrapping the {{AvroSerializerProvider}}.
> This results in failed writes, corrupted data and another fun.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 6 months
[JBoss JIRA] (ISPN-3942) HotRod client keep trying recover a connection to a cluster member after shutdown
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3942?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated ISPN-3942:
------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1059277, https://bugzilla.redhat.com/show_bug.cgi?id=1135520 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1059277)
> HotRod client keep trying recover a connection to a cluster member after shutdown
> ---------------------------------------------------------------------------------
>
> Key: ISPN-3942
> URL: https://issues.jboss.org/browse/ISPN-3942
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Remote Protocols
> Affects Versions: 6.0.1.Final, 7.0.0.Alpha1
> Environment: Infinispan server with HotRod client in server-client mode and replicated caches.
> Reporter: Wolf-Dieter Fink
> Assignee: Pedro Ruivo
> Priority: Critical
> Labels: 630, clustered, hotrod, hotrod-java-client
> Fix For: 7.0.0.Alpha2, 7.0.0.Final
>
> Attachments: hotrod-client.log
>
>
> If a HotRod client is connected to a server cluster and one of the servers do a correct shutdown, the client keep try to reconnect the server after the cluster view has changed.
> There is only a replicated cache configured.
> From the server-logfile the new cluster view is established
> 16:00:22,290 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-3,shared=udp) ISPN000094: Received new cluster view: [node1/clustered|2] (1) [node1/clustered]
> There is no failure from the application perspective, but there there is always a retry if the RoundRobin return the unavailable server.
> This might end in a performance or failure issue if there is a larger cluster and a part going out of work for some reason.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 6 months
[JBoss JIRA] (ISPN-4674) Hot Rod client receives ArrayIndexOutOfBoundsException and InvalidResponseException when topology changes
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-4674?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-4674:
-----------------------------------
Status: Pull Request Sent (was: Coding In Progress)
Git Pull Request: https://github.com/infinispan/infinispan/pull/2828
> Hot Rod client receives ArrayIndexOutOfBoundsException and InvalidResponseException when topology changes
> ---------------------------------------------------------------------------------------------------------
>
> Key: ISPN-4674
> URL: https://issues.jboss.org/browse/ISPN-4674
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Remote Protocols
> Affects Versions: 7.0.0.Beta1
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Priority: Critical
> Fix For: 7.0.0.Beta2
>
>
> Upon a topology change, the client receives:
> {code}
> 17:27:57,406 WARNING [com.example.Main] (main) Loop 43058 failed.: java.lang.ArrayIndexOutOfBoundsException: 2
> at org.infinispan.client.hotrod.impl.protocol.Codec20.readNewTopologyAndHash(Codec20.java:334) [infinispan-client-hotrod-7.0.0.Beta1.jar:7.0.0.Beta1]
> at org.infinispan.client.hotrod.impl.protocol.Codec20.readNewTopologyIfPresent(Codec20.java:310) [infinispan-client-hotrod-7.0.0.Beta1.jar:7.0.0.Beta1]
> at org.infinispan.client.hotrod.impl.protocol.Codec20.readPartialHeader(Codec20.java:78) [infinispan-client-hotrod-7.0.0.Beta1.jar:7.0.0.Beta1]
> at org.infinispan.client.hotrod.impl.protocol.Codec20.readHeader(Codec20.java:71) [infinispan-client-hotrod-7.0.0.Beta1.jar:7.0.0.Beta1]
> at org.infinispan.client.hotrod.impl.operations.HotRodOperation.readHeaderAndValidate(HotRodOperation.java:56) [infinispan-client-hotrod-7.0.0.Beta1.jar:7.0.0.Beta1]
> at org.infinispan.client.hotrod.impl.operations.AbstractKeyValueOperation.sendPutOperation(AbstractKeyValueOperation.java:50) [infinispan-client-hotrod-7.0.0.Beta1.jar:7.0.0.Beta1]
> at org.infinispan.client.hotrod.impl.operations.PutOperation.executeOperation(PutOperation.java:30) [infinispan-client-hotrod-7.0.0.Beta1.jar:7.0.0.Beta1]
> at org.infinispan.client.hotrod.impl.operations.PutOperation.executeOperation(PutOperation.java:19) [infinispan-client-hotrod-7.0.0.Beta1.jar:7.0.0.Beta1]
> at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:49) [infinispan-client-hotrod-7.0.0.Beta1.jar:7.0.0.Beta1]
> at org.infinispan.client.hotrod.impl.RemoteCacheImpl.put(RemoteCacheImpl.java:237) [infinispan-client-hotrod-7.0.0.Beta1.jar:7.0.0.Beta1]
> at org.infinispan.client.hotrod.impl.RemoteCacheSupport.put(RemoteCacheSupport.java:79) [infinispan-client-hotrod-7.0.0.Beta1.jar:7.0.0.Beta1]
> at com.example.Main.main(Main.java:31) [:]
> 17:28:02,410 ERROR [org.infinispan.client.hotrod.impl.protocol.Codec20] (main) ISPN004003: Invalid magic number. Expected 0xa1 and received 0x0
> 17:28:02,412 WARNING [com.example.Main] (main) Loop 43059 failed.: org.infinispan.client.hotrod.exceptions.InvalidResponseException:: Invalid magic number. Expected 0xa1 and received 0x0
> at org.infinispan.client.hotrod.impl.protocol.Codec20.readMagic(Codec20.java:247) [infinispan-client-hotrod-7.0.0.Beta1.jar:7.0.0.Beta1]
> at org.infinispan.client.hotrod.impl.protocol.Codec20.readHeader(Codec20.java:68) [infinispan-client-hotrod-7.0.0.Beta1.jar:7.0.0.Beta1]
> at org.infinispan.client.hotrod.impl.operations.HotRodOperation.readHeaderAndValidate(HotRodOperation.java:56) [infinispan-client-hotrod-7.0.0.Beta1.jar:7.0.0.Beta1]
> at org.infinispan.client.hotrod.impl.operations.AbstractKeyValueOperation.sendPutOperation(AbstractKeyValueOperation.java:50) [infinispan-client-hotrod-7.0.0.Beta1.jar:7.0.0.Beta1]
> at org.infinispan.client.hotrod.impl.operations.PutOperation.executeOperation(PutOperation.java:30) [infinispan-client-hotrod-7.0.0.Beta1.jar:7.0.0.Beta1]
> at org.infinispan.client.hotrod.impl.operations.PutOperation.executeOperation(PutOperation.java:19) [infinispan-client-hotrod-7.0.0.Beta1.jar:7.0.0.Beta1]
> at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:49) [infinispan-client-hotrod-7.0.0.Beta1.jar:7.0.0.Beta1]
> at org.infinispan.client.hotrod.impl.RemoteCacheImpl.put(RemoteCacheImpl.java:237) [infinispan-client-hotrod-7.0.0.Beta1.jar:7.0.0.Beta1]
> at org.infinispan.client.hotrod.impl.RemoteCacheSupport.put(RemoteCacheSupport.java:79) [infinispan-client-hotrod-7.0.0.Beta1.jar:7.0.0.Beta1]
> at com.example.Main.main(Main.java:31) [:]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 6 months