[JBoss JIRA] (ISPN-2783) Query on Invalidation cache fails in case of non-InfinispanDirectoryProvider
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-2783?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero updated ISPN-2783:
----------------------------------
Fix Version/s: (was: 5.3.0.Final)
(was: 5.2.1)
Affects Version/s: (was: 5.2.0.Final)
> Query on Invalidation cache fails in case of non-InfinispanDirectoryProvider
> ----------------------------------------------------------------------------
>
> Key: ISPN-2783
> URL: https://issues.jboss.org/browse/ISPN-2783
> Project: Infinispan
> Issue Type: Bug
> Components: Querying
> Reporter: Anna Manukyan
> Attachments: ClusteredInvalidationCacheTest.java
>
>
> Assume that node1 contains entries, node2 doesn't. And assume, that the cache on both nodes is configured as:
> {code}
> ConfigurationBuilder cacheCfg = getDefaultClusteredCacheConfig(CacheMode.INVALIDATION_SYNC, false);
> cacheCfg.indexing()
> .enable()
> .indexLocalOnly(true)
> .addProperty("default.directory_provider", "ram")
> .addProperty("lucene_version", "LUCENE_CURRENT") ;
>
> List<Cache<String, Person>> caches = createClusteredCaches(2, cacheCfg);
> {code}
> If I'm running the query on node1, then the query proceeds properly.
> If I'm running the query on node2, then I'm getting the following exception:
> {code}
> org.hibernate.search.SearchException: There are no mapped entities. Don't forget to add @Indexed to at least one class.
> at org.hibernate.search.query.engine.impl.HSQueryImpl.buildSearcher(HSQueryImpl.java:534)
> at org.hibernate.search.query.engine.impl.HSQueryImpl.buildSearcher(HSQueryImpl.java:511)
> at org.hibernate.search.query.engine.impl.HSQueryImpl.queryEntityInfos(HSQueryImpl.java:249)
> at org.infinispan.query.impl.CacheQueryImpl.list(CacheQueryImpl.java:170)
> at org.infinispan.query.blackbox.ClusteredInvalidationCacheTest.testSimple(ClusteredInvalidationCacheTest.java:119)
> {code}
> You can find the test attached.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months
[JBoss JIRA] (ISPN-2783) Query on Invalidation cache fails in case of non-InfinispanDirectoryProvider
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-2783?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero resolved ISPN-2783.
-----------------------------------
Resolution: Rejected
Query not supported on a Cache using Invalidation mode
> Query on Invalidation cache fails in case of non-InfinispanDirectoryProvider
> ----------------------------------------------------------------------------
>
> Key: ISPN-2783
> URL: https://issues.jboss.org/browse/ISPN-2783
> Project: Infinispan
> Issue Type: Bug
> Components: Querying
> Reporter: Anna Manukyan
> Attachments: ClusteredInvalidationCacheTest.java
>
>
> Assume that node1 contains entries, node2 doesn't. And assume, that the cache on both nodes is configured as:
> {code}
> ConfigurationBuilder cacheCfg = getDefaultClusteredCacheConfig(CacheMode.INVALIDATION_SYNC, false);
> cacheCfg.indexing()
> .enable()
> .indexLocalOnly(true)
> .addProperty("default.directory_provider", "ram")
> .addProperty("lucene_version", "LUCENE_CURRENT") ;
>
> List<Cache<String, Person>> caches = createClusteredCaches(2, cacheCfg);
> {code}
> If I'm running the query on node1, then the query proceeds properly.
> If I'm running the query on node2, then I'm getting the following exception:
> {code}
> org.hibernate.search.SearchException: There are no mapped entities. Don't forget to add @Indexed to at least one class.
> at org.hibernate.search.query.engine.impl.HSQueryImpl.buildSearcher(HSQueryImpl.java:534)
> at org.hibernate.search.query.engine.impl.HSQueryImpl.buildSearcher(HSQueryImpl.java:511)
> at org.hibernate.search.query.engine.impl.HSQueryImpl.queryEntityInfos(HSQueryImpl.java:249)
> at org.infinispan.query.impl.CacheQueryImpl.list(CacheQueryImpl.java:170)
> at org.infinispan.query.blackbox.ClusteredInvalidationCacheTest.testSimple(ClusteredInvalidationCacheTest.java:119)
> {code}
> You can find the test attached.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months
[JBoss JIRA] (ISPN-2710) Huge amount of OOB threads during performance test
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2710?page=com.atlassian.jira.plugin.... ]
Mircea Markus commented on ISPN-2710:
-------------------------------------
ISPN-825 should virtually halve the number of OOB threads in use at any time, as when fetching remote values we currently go to all owners: 1 remote get results in numOwners OOB threads used. ISPN-825 would make 1 remote get always use 1 OOB thread.
> Huge amount of OOB threads during performance test
> --------------------------------------------------
>
> Key: ISPN-2710
> URL: https://issues.jboss.org/browse/ISPN-2710
> Project: Infinispan
> Issue Type: Feature Request
> Affects Versions: 5.2.0.CR1
> Reporter: Robert Stupp
> Assignee: Mircea Markus
>
> While running our performance test (as described in ISPN-2240), two of the four servers are running at 80 to 100% CPU - while the others just run at 10%.
> Before that phenomenom a huge amount (several 100s) of threads has been created (all called {{OOB-xxxx}}.
> The performance test just reads cached data - there was no cache put operation at that time.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months
[JBoss JIRA] (ISPN-2782) Query on the cache with Invalidation mode fails
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-2782?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero resolved ISPN-2782.
-----------------------------------
Resolution: Rejected
Invalidation is not supported in combination with Query
> Query on the cache with Invalidation mode fails
> -----------------------------------------------
>
> Key: ISPN-2782
> URL: https://issues.jboss.org/browse/ISPN-2782
> Project: Infinispan
> Issue Type: Bug
> Components: Querying
> Affects Versions: 5.2.0.Final
> Reporter: Anna Manukyan
> Assignee: Sanne Grinovero
> Attachments: ClusteredInvalidationCacheTest.java
>
>
> Assume that we have 2 nodes. node1 contains data entries, node2 doesn't.
> When configuring cache in the following way:
> {code}
> ConfigurationBuilder cacheCfg = getDefaultClusteredCacheConfig(CacheMode.INVALIDATION_SYNC, false);
> cacheCfg.indexing()
> .enable()
> .indexLocalOnly(true)
> .addProperty("default.directory_provider", "infinispan")
> .addProperty("default.indexmanager", "org.infinispan.query.indexmanager.InfinispanIndexManager")
> .addProperty("lucene_version", "LUCENE_CURRENT")
> .addProperty("default.exclusive_index_use", "false");
> List<Cache<String, Person>> caches = createClusteredCaches(2, cacheCfg);
> {code}
> And running query on node1 cache, the following exception appears:
> {code}
> org.hibernate.search.SearchException: Unable to reopen IndexReader
> at org.hibernate.search.indexes.impl.SharingBufferReaderProvider$PerDirectoryLatestReader.refreshAndGet(SharingBufferReaderProvider.java:253)
> at org.hibernate.search.indexes.impl.SharingBufferReaderProvider.openIndexReader(SharingBufferReaderProvider.java:85)
> at org.hibernate.search.reader.impl.MultiReaderFactory.openReader(MultiReaderFactory.java:49)
> at org.hibernate.search.query.engine.impl.HSQueryImpl.buildSearcher(HSQueryImpl.java:612)
> at org.hibernate.search.query.engine.impl.HSQueryImpl.buildSearcher(HSQueryImpl.java:511)
> at org.hibernate.search.query.engine.impl.HSQueryImpl.queryEntityInfos(HSQueryImpl.java:249)
> at org.infinispan.query.impl.CacheQueryImpl.list(CacheQueryImpl.java:170)
> at org.infinispan.query.blackbox.ClusteredInvalidationCacheTest.testSimple(ClusteredInvalidationCacheTest.java:126)
> 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: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.runSequentially(SuiteRunner.java:329)
> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291)
> at org.testng.SuiteRunner.run(SuiteRunner.java:240)
> at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
> at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
> at org.testng.TestNG.runSuitesSequentially(TestNG.java:1198)
> at org.testng.TestNG.runSuitesLocally(TestNG.java:1123)
> at org.testng.TestNG.run(TestNG.java:1031)
> at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:111)
> at org.testng.remote.RemoteTestNG.initAndRun(RemoteTestNG.java:204)
> at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:175)
> at org.testng.RemoteTestNGStarter.main(RemoteTestNGStarter.java:111)
> 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 com.intellij.rt.execution.application.AppMain.main(AppMain.java:120)
> Caused by: org.apache.lucene.index.IndexNotFoundException: no segments* file found in InfinispanDirectory{indexName='person'}: files: []
> at org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:667)
> at org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:554)
> at org.apache.lucene.index.SegmentInfos.read(SegmentInfos.java:359)
> at org.apache.lucene.index.SegmentInfos.readCurrentVersion(SegmentInfos.java:483)
> at org.apache.lucene.index.DirectoryReader.isCurrent(DirectoryReader.java:891)
> at org.apache.lucene.index.DirectoryReader.doOpenNoWriter(DirectoryReader.java:455)
> at org.apache.lucene.index.DirectoryReader.doOpenIfChanged(DirectoryReader.java:434)
> at org.apache.lucene.index.DirectoryReader.doOpenIfChanged(DirectoryReader.java:375)
> at org.apache.lucene.index.IndexReader.openIfChanged(IndexReader.java:508)
> at org.hibernate.search.indexes.impl.SharingBufferReaderProvider$PerDirectoryLatestReader.refreshAndGet(SharingBufferReaderProvider.java:250)
> ... 37 more
> {code}
> Additionally, in case if "default.exclusive_index_use" property is set to true or just not set (default is true), then the additionally this exception appears:
> {code}
> 2013-01-31 17:28:51,850 ERROR [LogErrorHandler] (Hibernate Search: Index updates queue processor for index person-1) HSEARCH000058: Exception occurred org.apache.lucene.store.LockObtainFailedException: Lock obtain timed out: org.infinispan.lucene.locking.BaseLuceneLock@467110d4
> Primary Failure:
> Entity org.infinispan.query.test.Person Id S:BigGoat Work Type org.hibernate.search.backend.UpdateLuceneWork
> org.apache.lucene.store.LockObtainFailedException: Lock obtain timed out: org.infinispan.lucene.locking.BaseLuceneLock@467110d4
> at org.apache.lucene.store.Lock.obtain(Lock.java:84)
> at org.apache.lucene.index.IndexWriter.<init>(IndexWriter.java:1098)
> at org.hibernate.search.backend.impl.lucene.IndexWriterHolder.createNewIndexWriter(IndexWriterHolder.java:148)
> at org.hibernate.search.backend.impl.lucene.IndexWriterHolder.getIndexWriter(IndexWriterHolder.java:115)
> at org.hibernate.search.backend.impl.lucene.AbstractWorkspaceImpl.getIndexWriter(AbstractWorkspaceImpl.java:117)
> at org.hibernate.search.backend.impl.lucene.LuceneBackendQueueTask.applyUpdates(LuceneBackendQueueTask.java:99)
> at org.hibernate.search.backend.impl.lucene.LuceneBackendQueueTask.run(LuceneBackendQueueTask.java:67)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> 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)
> 2013-01-31 17:28:51,852 ERROR [LuceneBackendQueueTask] (Hibernate Search: Index updates queue processor for index person-1) HSEARCH000072: Couldn't open the IndexWriter because of previous error: operation skipped, index ouf of sync!
> 2013-01-31 17:28:52,857 ERROR [LogErrorHandler] (Hibernate Search: Index updates queue processor for index person-1) HSEARCH000058: Exception occurred org.apache.lucene.store.LockObtainFailedException: Lock obtain timed out: org.infinispan.lucene.locking.BaseLuceneLock@467110d4
> Primary Failure:
> Entity org.infinispan.query.test.Person Id S:MiniGoat Work Type org.hibernate.search.backend.UpdateLuceneWork
> org.apache.lucene.store.LockObtainFailedException: Lock obtain timed out: org.infinispan.lucene.locking.BaseLuceneLock@467110d4
> at org.apache.lucene.store.Lock.obtain(Lock.java:84)
> at org.apache.lucene.index.IndexWriter.<init>(IndexWriter.java:1098)
> at org.hibernate.search.backend.impl.lucene.IndexWriterHolder.createNewIndexWriter(IndexWriterHolder.java:148)
> at org.hibernate.search.backend.impl.lucene.IndexWriterHolder.getIndexWriter(IndexWriterHolder.java:115)
> at org.hibernate.search.backend.impl.lucene.AbstractWorkspaceImpl.getIndexWriter(AbstractWorkspaceImpl.java:117)
> at org.hibernate.search.backend.impl.lucene.LuceneBackendQueueTask.applyUpdates(LuceneBackendQueueTask.java:99)
> at org.hibernate.search.backend.impl.lucene.LuceneBackendQueueTask.run(LuceneBackendQueueTask.java:67)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> 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)
> 2013-01-31 17:28:52,858 ERROR [LuceneBackendQueueTask] (Hibernate Search: Index updates queue processor for index person-1) HSEARCH000072: Couldn't open the IndexWriter because of previous error: operation skipped, index ouf of sync!
> {code}
> You can find the tests attached.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months
[JBoss JIRA] (ISPN-825) Consider staggering remote get requests when using DIST
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-825?page=com.atlassian.jira.plugin.s... ]
Mircea Markus updated ISPN-825:
-------------------------------
Fix Version/s: 5.3.0.Final
(was: 6.0.0.Final)
> Consider staggering remote get requests when using DIST
> -------------------------------------------------------
>
> Key: ISPN-825
> URL: https://issues.jboss.org/browse/ISPN-825
> Project: Infinispan
> Issue Type: Feature Request
> Components: RPC
> Affects Versions: 4.1.0.Final
> Reporter: Manik Surtani
> Assignee: Mircea Markus
> Labels: optimization, performance
> Fix For: 5.3.0.Final
>
>
> In DIST mode, when a request is made on a key that is not mapped locally, a remote get is sent to all data owners of that key and the first response is used. This can add unnecessary load on the network as all nodes still eventually respond, and if values are large this can cause a lot of unnecessary network traffic.
> The purpose of broadcasting to all data owners is so that (1) if one is down, another could still respond (2) if one is overloaded, others may respond faster.
> A solution around this could be based on either (or both) of:
> * Provide a configurable stagger timeout, e.g. 100ms. E.g., RPC to (random) Owner1. Wait for timeout t. If no response, RPC to Owner2. etc.
> * Always broadcast to a (configurable) subset of owners, e.g., always 2 even if numOwners is 5.
> Needs careful thought and design.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months
[JBoss JIRA] (ISPN-2797) Support Query on Caches configured with INVALIDATION mode
by Sanne Grinovero (JIRA)
Sanne Grinovero created ISPN-2797:
-------------------------------------
Summary: Support Query on Caches configured with INVALIDATION mode
Key: ISPN-2797
URL: https://issues.jboss.org/browse/ISPN-2797
Project: Infinispan
Issue Type: Feature Request
Components: Querying
Reporter: Sanne Grinovero
Assignee: Sanne Grinovero
Fix For: 6.0.0.Final
This is currently not supported as other nodes won't get a copy of the value, and are consequentially unable to scan annotations or recognize new services which need to be started.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months
[JBoss JIRA] (ISPN-2645) LocalKeyAffinityServiceTest.testFilteredRemoveServers fails randomly
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2645?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2645:
--------------------------------
Fix Version/s: 5.2.1
> LocalKeyAffinityServiceTest.testFilteredRemoveServers fails randomly
> --------------------------------------------------------------------
>
> Key: ISPN-2645
> URL: https://issues.jboss.org/browse/ISPN-2645
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Cache, Test Suite
> Affects Versions: 5.2.0.Beta5
> Reporter: Dan Berindei
> Assignee: Mircea Markus
> Labels: testsuite_stability
> Fix For: 5.2.1, 5.3.0.Final
>
>
> LocalKeyAffinityServiceTest tests that KeyAffinnityServiceImpl's internal queues eventually fill up, and it fails:
> {noformat}
> java.lang.AssertionError: expected [true] but found [false]
> at org.testng.Assert.fail(Assert.java:89)
> at org.testng.Assert.failNotEquals(Assert.java:489)
> at org.testng.Assert.assertTrue(Assert.java:37)
> at org.testng.Assert.assertTrue(Assert.java:47)
> at org.infinispan.test.AbstractInfinispanTest.eventually(AbstractInfinispanTest.java:76)
> at org.infinispan.test.AbstractInfinispanTest.eventually(AbstractInfinispanTest.java:59)
> at org.infinispan.affinity.BaseKeyAffinityServiceTest.assertEventualFullCapacity(BaseKeyAffinityServiceTest.java:98)
> at org.infinispan.affinity.BaseFilterKeyAffinityServiceTest.assertUnaffected(BaseFilterKeyAffinityServiceTest.java:108)
> at org.infinispan.affinity.BaseFilterKeyAffinityServiceTest.testRemoveServers(BaseFilterKeyAffinityServiceTest.java:82)
> at org.infinispan.affinity.LocalKeyAffinityServiceTest.testFilteredRemoveServers(LocalKeyAffinityServiceTest.java:66)
> {noformat}
> I have added some TRACE logs to KeyAffinityServiceImpl and it looks like the queue fills up immediately, but it could be that a new queue is created and the test is checking the wrong queue object.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months
[JBoss JIRA] (ISPN-2614) org.infinispan.marshall.MarshallExternalPojosTest.testReplicateJBossExternalizePojoToNewJoiningNode fails randomly
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2614?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2614:
--------------------------------
Fix Version/s: 5.2.1
5.3.0.Final
> org.infinispan.marshall.MarshallExternalPojosTest.testReplicateJBossExternalizePojoToNewJoiningNode fails randomly
> ------------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-2614
> URL: https://issues.jboss.org/browse/ISPN-2614
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.2.0.Beta5
> Reporter: Anna Manukyan
> Assignee: Mircea Markus
> Labels: testsuite_stability
> Fix For: 5.2.1, 5.3.0.Final
>
>
> The test org.infinispan.marshall.MarshallExternalPojosTest.testReplicateJBossExternalizePojoToNewJoiningNode fails randomly on all environments - Windows, Solaris, RHEL - jdk7 & openjdk7
> The failure is:
> {code}
> Error Message
> Replication timeout for MarshallExternalPojosTest-NodeD-24038
> Stacktrace
> org.infinispan.util.concurrent.TimeoutException: Replication timeout for MarshallExternalPojosTest-NodeD-24038
> at org.infinispan.remoting.transport.AbstractTransport.parseResponseAndAddToResponseList(AbstractTransport.java:110)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:541)
> at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:180)
> at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:202)
> at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:259)
> at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:246)
> at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:241)
> at org.infinispan.remoting.rpc.RpcManagerImpl.broadcastRpcCommand(RpcManagerImpl.java:220)
> at org.infinispan.remoting.rpc.RpcManagerImpl.broadcastRpcCommand(RpcManagerImpl.java:212)
> at org.infinispan.interceptors.ReplicationInterceptor.handleCrudMethod(ReplicationInterceptor.java:280)
> at org.infinispan.interceptors.ReplicationInterceptor.visitPutKeyValueCommand(ReplicationInterceptor.java:244)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:77)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.EntryWrappingInterceptor.invokeNextAndApplyChanges(EntryWrappingInterceptor.java:211)
> at org.infinispan.interceptors.EntryWrappingInterceptor.visitPutKeyValueCommand(EntryWrappingInterceptor.java:149)
> 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.NonTransactionalLockingInterceptor.visitPutKeyValueCommand(NonTransactionalLockingInterceptor.java:70)
> 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.statetransfer.StateTransferInterceptor.handleTopologyAffectedCommand(StateTransferInterceptor.java:214)
> at org.infinispan.statetransfer.StateTransferInterceptor.handleWriteCommand(StateTransferInterceptor.java:192)
> at org.infinispan.statetransfer.StateTransferInterceptor.visitPutKeyValueCommand(StateTransferInterceptor.java:135)
> 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:1016)
> at org.infinispan.CacheImpl.put(CacheImpl.java:712)
> at org.infinispan.CacheImpl.put(CacheImpl.java:704)
> at org.infinispan.CacheSupport.put(CacheSupport.java:53)
> at org.infinispan.marshall.MarshallExternalPojosTest.doReplicatePojoToNewJoiningNode(MarshallExternalPojosTest.java:91)
> at org.infinispan.marshall.MarshallExternalPojosTest.testReplicateMarshallableByPojoToNewJoiningNode(MarshallExternalPojosTest.java:76)
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months