[JBoss JIRA] (ISPN-2550) NoSuchElementException in Hot Rod Encoder
by Michal Linhard (JIRA)
[ https://issues.jboss.org/browse/ISPN-2550?page=com.atlassian.jira.plugin.... ]
Michal Linhard commented on ISPN-2550:
--------------------------------------
900MB of tasty tracelogs from runs with 5.2.0.Beta5 (resilience tests on hudson / perflab)
http://www.qa.jboss.com/~mlinhard/test_results/serverlogs-trace-ispn2550.zip
njoy!
> NoSuchElementException in Hot Rod Encoder
> -----------------------------------------
>
> Key: ISPN-2550
> URL: https://issues.jboss.org/browse/ISPN-2550
> Project: Infinispan
> Issue Type: Bug
> Components: Remote protocols
> Affects Versions: 5.2.0.Beta4
> Reporter: Michal Linhard
> Assignee: Galder Zamarreño
> Priority: Blocker
> Fix For: 5.2.0.Beta6
>
>
> Tomas noticed this a while ago in a specific functional test:
> https://bugzilla.redhat.com/show_bug.cgi?id=875151
> I'm creating a more general JIRA, cause I'm having this in resilience test.
> What I found by quick debug, is that here:
> https://github.com/infinispan/infinispan/blob/master/server/hotrod/src/ma...
> {code}
> for (segmentIdx <- 0 until numSegments) {
> val denormalizedSegmentHashIds = allDenormalizedHashIds(segmentIdx)
> val segmentOwners = ch.locateOwnersForSegment(segmentIdx)
> for (ownerIdx <- 0 until segmentOwners.length) {
> val address = segmentOwners(ownerIdx % segmentOwners.size)
> val serverAddress = members(address)
> val hashId = denormalizedSegmentHashIds(ownerIdx)
> log.tracef("Writing hash id %d for %s:%s", hashId, serverAddress.host, serverAddress.port)
> writeString(serverAddress.host, buf)
> writeUnsignedShort(serverAddress.port, buf)
> buf.writeInt(hashId)
> }
> }
> {code}
> we're trying to obtain serverAddress for nonexistent address and NoSuchElementException is not handled properly.
> It hapens after I kill a node in a resilience test and the exception appears when querying for the node in the members cache.
--
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, 3 months
[JBoss JIRA] (ISPN-2550) NoSuchElementException in Hot Rod Encoder
by Michal Linhard (JIRA)
[ https://issues.jboss.org/browse/ISPN-2550?page=com.atlassian.jira.plugin.... ]
Michal Linhard commented on ISPN-2550:
--------------------------------------
Dan, I wanted to try your change, but I don't see any further commit on the branch https://github.com/danberindei/infinispan/tree/t_2550_m
> NoSuchElementException in Hot Rod Encoder
> -----------------------------------------
>
> Key: ISPN-2550
> URL: https://issues.jboss.org/browse/ISPN-2550
> Project: Infinispan
> Issue Type: Bug
> Components: Remote protocols
> Affects Versions: 5.2.0.Beta4
> Reporter: Michal Linhard
> Assignee: Galder Zamarreño
> Priority: Blocker
> Fix For: 5.2.0.Beta6
>
>
> Tomas noticed this a while ago in a specific functional test:
> https://bugzilla.redhat.com/show_bug.cgi?id=875151
> I'm creating a more general JIRA, cause I'm having this in resilience test.
> What I found by quick debug, is that here:
> https://github.com/infinispan/infinispan/blob/master/server/hotrod/src/ma...
> {code}
> for (segmentIdx <- 0 until numSegments) {
> val denormalizedSegmentHashIds = allDenormalizedHashIds(segmentIdx)
> val segmentOwners = ch.locateOwnersForSegment(segmentIdx)
> for (ownerIdx <- 0 until segmentOwners.length) {
> val address = segmentOwners(ownerIdx % segmentOwners.size)
> val serverAddress = members(address)
> val hashId = denormalizedSegmentHashIds(ownerIdx)
> log.tracef("Writing hash id %d for %s:%s", hashId, serverAddress.host, serverAddress.port)
> writeString(serverAddress.host, buf)
> writeUnsignedShort(serverAddress.port, buf)
> buf.writeInt(hashId)
> }
> }
> {code}
> we're trying to obtain serverAddress for nonexistent address and NoSuchElementException is not handled properly.
> It hapens after I kill a node in a resilience test and the exception appears when querying for the node in the members cache.
--
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, 3 months
[JBoss JIRA] (ISPN-2550) NoSuchElementException in Hot Rod Encoder
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-2550?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-2550:
------------------------------------
The IndexOutOfBoundsException seems to appear because we're generating numOwners (2) "denormalized" hash ids for each segment, but the consistent hash has more than owners for one segment (3). This can happen during a join, when the write CH is a union between the previous CH and the new, balanced, CH.
Tomas, I've updated my branch to use the read CH instead, could you try again?
> NoSuchElementException in Hot Rod Encoder
> -----------------------------------------
>
> Key: ISPN-2550
> URL: https://issues.jboss.org/browse/ISPN-2550
> Project: Infinispan
> Issue Type: Bug
> Components: Remote protocols
> Affects Versions: 5.2.0.Beta4
> Reporter: Michal Linhard
> Assignee: Galder Zamarreño
> Priority: Blocker
> Fix For: 5.2.0.Beta6
>
>
> Tomas noticed this a while ago in a specific functional test:
> https://bugzilla.redhat.com/show_bug.cgi?id=875151
> I'm creating a more general JIRA, cause I'm having this in resilience test.
> What I found by quick debug, is that here:
> https://github.com/infinispan/infinispan/blob/master/server/hotrod/src/ma...
> {code}
> for (segmentIdx <- 0 until numSegments) {
> val denormalizedSegmentHashIds = allDenormalizedHashIds(segmentIdx)
> val segmentOwners = ch.locateOwnersForSegment(segmentIdx)
> for (ownerIdx <- 0 until segmentOwners.length) {
> val address = segmentOwners(ownerIdx % segmentOwners.size)
> val serverAddress = members(address)
> val hashId = denormalizedSegmentHashIds(ownerIdx)
> log.tracef("Writing hash id %d for %s:%s", hashId, serverAddress.host, serverAddress.port)
> writeString(serverAddress.host, buf)
> writeUnsignedShort(serverAddress.port, buf)
> buf.writeInt(hashId)
> }
> }
> {code}
> we're trying to obtain serverAddress for nonexistent address and NoSuchElementException is not handled properly.
> It hapens after I kill a node in a resilience test and the exception appears when querying for the node in the members cache.
--
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, 3 months
[JBoss JIRA] (ISPN-2550) NoSuchElementException in Hot Rod Encoder
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-2550?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-2550:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> made a comment on [bug 875151|https://bugzilla.redhat.com/show_bug.cgi?id=875151]
Yes, RCMs get the server list dynamically from the servers. However only the servers with an endpoint should add their address to the list.
> NoSuchElementException in Hot Rod Encoder
> -----------------------------------------
>
> Key: ISPN-2550
> URL: https://issues.jboss.org/browse/ISPN-2550
> Project: Infinispan
> Issue Type: Bug
> Components: Remote protocols
> Affects Versions: 5.2.0.Beta4
> Reporter: Michal Linhard
> Assignee: Galder Zamarreño
> Priority: Blocker
> Fix For: 5.2.0.Beta6
>
>
> Tomas noticed this a while ago in a specific functional test:
> https://bugzilla.redhat.com/show_bug.cgi?id=875151
> I'm creating a more general JIRA, cause I'm having this in resilience test.
> What I found by quick debug, is that here:
> https://github.com/infinispan/infinispan/blob/master/server/hotrod/src/ma...
> {code}
> for (segmentIdx <- 0 until numSegments) {
> val denormalizedSegmentHashIds = allDenormalizedHashIds(segmentIdx)
> val segmentOwners = ch.locateOwnersForSegment(segmentIdx)
> for (ownerIdx <- 0 until segmentOwners.length) {
> val address = segmentOwners(ownerIdx % segmentOwners.size)
> val serverAddress = members(address)
> val hashId = denormalizedSegmentHashIds(ownerIdx)
> log.tracef("Writing hash id %d for %s:%s", hashId, serverAddress.host, serverAddress.port)
> writeString(serverAddress.host, buf)
> writeUnsignedShort(serverAddress.port, buf)
> buf.writeInt(hashId)
> }
> }
> {code}
> we're trying to obtain serverAddress for nonexistent address and NoSuchElementException is not handled properly.
> It hapens after I kill a node in a resilience test and the exception appears when querying for the node in the members cache.
--
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, 3 months
[JBoss JIRA] (ISPN-2550) NoSuchElementException in Hot Rod Encoder
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-2550?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-2550:
-----------------------------------------------
Martin Gencur <mgencur(a)redhat.com> made a comment on [bug 875151|https://bugzilla.redhat.com/show_bug.cgi?id=875151]
Just a note about the test: When we create a RemoteCacheManager and passing just one address to it, it does *not* mean that all requsts through cache.put/get will go just to this one address but possibly to all nodes in the cluster. Is that right? AFAIK the HotRod client is dynamically getting the information about all clustered nodes and autonomously chooses one of the cluster nodes to send requests to. If my assumption is correct, we would need to use Memcached or REST client to properly test the storage-only example, not HotRod.
> NoSuchElementException in Hot Rod Encoder
> -----------------------------------------
>
> Key: ISPN-2550
> URL: https://issues.jboss.org/browse/ISPN-2550
> Project: Infinispan
> Issue Type: Bug
> Components: Remote protocols
> Affects Versions: 5.2.0.Beta4
> Reporter: Michal Linhard
> Assignee: Galder Zamarreño
> Priority: Blocker
> Fix For: 5.2.0.Beta6
>
>
> Tomas noticed this a while ago in a specific functional test:
> https://bugzilla.redhat.com/show_bug.cgi?id=875151
> I'm creating a more general JIRA, cause I'm having this in resilience test.
> What I found by quick debug, is that here:
> https://github.com/infinispan/infinispan/blob/master/server/hotrod/src/ma...
> {code}
> for (segmentIdx <- 0 until numSegments) {
> val denormalizedSegmentHashIds = allDenormalizedHashIds(segmentIdx)
> val segmentOwners = ch.locateOwnersForSegment(segmentIdx)
> for (ownerIdx <- 0 until segmentOwners.length) {
> val address = segmentOwners(ownerIdx % segmentOwners.size)
> val serverAddress = members(address)
> val hashId = denormalizedSegmentHashIds(ownerIdx)
> log.tracef("Writing hash id %d for %s:%s", hashId, serverAddress.host, serverAddress.port)
> writeString(serverAddress.host, buf)
> writeUnsignedShort(serverAddress.port, buf)
> buf.writeInt(hashId)
> }
> }
> {code}
> we're trying to obtain serverAddress for nonexistent address and NoSuchElementException is not handled properly.
> It hapens after I kill a node in a resilience test and the exception appears when querying for the node in the members cache.
--
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, 3 months
[JBoss JIRA] (ISPN-2516) org.infinispan.distribution.topologyaware.TopologyAwareStateTransferTest.testNodeDown3 fails randomly
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-2516?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-2516:
-----------------------------------------------
Anna Manukyan <amanukya(a)redhat.com> made a comment on [bug 855350|https://bugzilla.redhat.com/show_bug.cgi?id=855350]
For ER5, the testNodeDown has been failed, and just in case the provided links will be broken, the error message is:
Error Message
Timed out waiting for rebalancing to complete on node TopologyAwareStateTransferTest-NodeA-23408, current topology is CacheTopology{id=9, currentCH=DefaultConsistentHash{numSegments=60, numOwners=2, members=[TopologyAwareStateTransferTest-NodeA-23408, TopologyAwareStateTransferTest-NodeB-47156, TopologyAwareStateTransferTest-NodeC-50852, TopologyAwareStateTransferTest-NodeD-5971], owners={0: 0 1, 1: 0 1, 2: 0 1, 3: 0 1, 4: 0 1, 5: 0 1, 6: 0 1, 7: 0 1, 8: 0 1, 9: 0 1, 10: 0 1, 11: 0 1, 12: 0, 13: 0, 14: 0, 15: 3 0, 16: 3 0, 17: 3 0, 18: 3 0, 19: 3 0, 20: 2 0, 21: 2 0, 22: 2 0, 23: 2 0, 24: 2 0, 25: 2 0, 26: 2 0, 27: 2 0, 28: 2 0, 29: 2 0, 30: 1 0, 31: 1 0, 32: 1 0, 33: 1 0, 34: 1 0, 35: 1 0, 36: 1 0, 37: 1 0, 38: 1 0, 39: 1 0, 40: 1 0, 41: 1 0, 42: 1, 43: 1, 44: 1, 45: 3 1, 46: 3 1, 47: 3 1, 48: 3 1, 49: 3 1, 50: 2 1, 51: 2 1, 52: 2, 53: 2, 54: 2, 55: 3 2, 56: 3 2, 57: 3, 58: 3, 59: 3}, pendingCH=DefaultConsistentHash{numSegments=60, numOwners=2, members=[TopologyAwareStateTransferTest-NodeA-23408, TopologyAwareStateTransferTest-NodeB-47156, TopologyAwareStateTransferTest-NodeC-50852, TopologyAwareStateTransferTest-NodeD-5971], owners={0: 0 1, 1: 0 1, 2: 0 1, 3: 0 1, 4: 0 1, 5: 0 1, 6: 0 1, 7: 0 1, 8: 0 1, 9: 0 1, 10: 0 1, 11: 0 1, 12: 0 2, 13: 0 2, 14: 0 2, 15: 3 0, 16: 3 0, 17: 3 0, 18: 3 0, 19: 3 0, 20: 2 0, 21: 2 0, 22: 2 0, 23: 2 0, 24: 2 0, 25: 2 0, 26: 2 0, 27: 2 0, 28: 2 0, 29: 2 0, 30: 1 0, 31: 1 0, 32: 1 0, 33: 1 0, 34: 1 0, 35: 1 0, 36: 1 0, 37: 1 0, 38: 1 0, 39: 1 0, 40: 1 0, 41: 1 0, 42: 1 2, 43: 1 2, 44: 1 2, 45: 3 1, 46: 3 1, 47: 3 1, 48: 3 1, 49: 3 1, 50: 2 1, 51: 2 1, 52: 2 3, 53: 2 3, 54: 2 3, 55: 3 2, 56: 3 2, 57: 3 2, 58: 3 2, 59: 3 2}}
Stacktrace
java.lang.RuntimeException: Timed out waiting for rebalancing to complete on node TopologyAwareStateTransferTest-NodeA-23408, current topology is CacheTopology{id=9, currentCH=DefaultConsistentHash{numSegments=60, numOwners=2, members=[TopologyAwareStateTransferTest-NodeA-23408, TopologyAwareStateTransferTest-NodeB-47156, TopologyAwareStateTransferTest-NodeC-50852, TopologyAwareStateTransferTest-NodeD-5971], owners={0: 0 1, 1: 0 1, 2: 0 1, 3: 0 1, 4: 0 1, 5: 0 1, 6: 0 1, 7: 0 1, 8: 0 1, 9: 0 1, 10: 0 1, 11: 0 1, 12: 0, 13: 0, 14: 0, 15: 3 0, 16: 3 0, 17: 3 0, 18: 3 0, 19: 3 0, 20: 2 0, 21: 2 0, 22: 2 0, 23: 2 0, 24: 2 0, 25: 2 0, 26: 2 0, 27: 2 0, 28: 2 0, 29: 2 0, 30: 1 0, 31: 1 0, 32: 1 0, 33: 1 0, 34: 1 0, 35: 1 0, 36: 1 0, 37: 1 0, 38: 1 0, 39: 1 0, 40: 1 0, 41: 1 0, 42: 1, 43: 1, 44: 1, 45: 3 1, 46: 3 1, 47: 3 1, 48: 3 1, 49: 3 1, 50: 2 1, 51: 2 1, 52: 2, 53: 2, 54: 2, 55: 3 2, 56: 3 2, 57: 3, 58: 3, 59: 3}, pendingCH=DefaultConsistentHash{numSegments=60, numOwners=2, members=[TopologyAwareStateTransferTest-NodeA-23408, TopologyAwareStateTransferTest-NodeB-47156, TopologyAwareStateTransferTest-NodeC-50852, TopologyAwareStateTransferTest-NodeD-5971], owners={0: 0 1, 1: 0 1, 2: 0 1, 3: 0 1, 4: 0 1, 5: 0 1, 6: 0 1, 7: 0 1, 8: 0 1, 9: 0 1, 10: 0 1, 11: 0 1, 12: 0 2, 13: 0 2, 14: 0 2, 15: 3 0, 16: 3 0, 17: 3 0, 18: 3 0, 19: 3 0, 20: 2 0, 21: 2 0, 22: 2 0, 23: 2 0, 24: 2 0, 25: 2 0, 26: 2 0, 27: 2 0, 28: 2 0, 29: 2 0, 30: 1 0, 31: 1 0, 32: 1 0, 33: 1 0, 34: 1 0, 35: 1 0, 36: 1 0, 37: 1 0, 38: 1 0, 39: 1 0, 40: 1 0, 41: 1 0, 42: 1 2, 43: 1 2, 44: 1 2, 45: 3 1, 46: 3 1, 47: 3 1, 48: 3 1, 49: 3 1, 50: 2 1, 51: 2 1, 52: 2 3, 53: 2 3, 54: 2 3, 55: 3 2, 56: 3 2, 57: 3 2, 58: 3 2, 59: 3 2}}
at org.infinispan.test.TestingUtil.waitForRehashToComplete(TestingUtil.java:198)
at org.infinispan.test.TestingUtil.waitForRehashToComplete(TestingUtil.java:208)
at org.infinispan.distribution.topologyaware.TopologyAwareStateTransferTest.testNodeDown(TopologyAwareStateTransferTest.java:100)
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)
> org.infinispan.distribution.topologyaware.TopologyAwareStateTransferTest.testNodeDown3 fails randomly
> -----------------------------------------------------------------------------------------------------
>
> Key: ISPN-2516
> URL: https://issues.jboss.org/browse/ISPN-2516
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite
> Reporter: Anna Manukyan
> Assignee: Mircea Markus
> Labels: testsuite_stability
>
> The test fails randomly on Rhel6x64 IBM7JDk (for JDG testsuite).
> You can find the log here:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/edg-60-ispn-testsuite...
> The bug doesn't appear when the test is run separately.
--
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, 3 months
[JBoss JIRA] (ISPN-2619) DistSyncCacheStoreNotSharedTest fails randomly
by Dan Berindei (JIRA)
Dan Berindei created ISPN-2619:
----------------------------------
Summary: DistSyncCacheStoreNotSharedTest fails randomly
Key: ISPN-2619
URL: https://issues.jboss.org/browse/ISPN-2619
Project: Infinispan
Issue Type: Bug
Components: Test Suite
Affects Versions: 5.2.0.Beta5
Reporter: Dan Berindei
Assignee: Mircea Markus
DistSyncCacheStoreNotSharedTest fails (pretty rarely) with this exception:
{noformat}
09:29:51,069 ERROR (testng-DistSyncCacheStoreNotSharedTest:) [UnitTestTestNGListener] Test testAtomicPutIfAbsentFromNonOwner(org.infinispan.distribution.DistSyncCacheStoreNotSharedTest) failed.
java.lang.AssertionError
at org.infinispan.distribution.DistSyncCacheStoreNotSharedTest.testAtomicPutIfAbsentFromNonOwner(DistSyncCacheStoreNotSharedTest.java:293)
{noformat}
What happens is that at the end of the previous test there is a get() that goes remotely, and one of the ClusteredGetCommands (to node C) is delayed. The test framework then clears the cache store and the data container on node C, but the get command already had the entry in its context and will write it to the data container when it finishes executing, so that the data container is not empty when testAtomicPutIfAbsentFromNonOwner starts.
{noformat}
09:29:51,033 TRACE (OOB-1,ISPN,NodeC-33167:) [CommandAwareRpcDispatcher] Attempting to execute command: ClusteredGetCommand{key=k2, flags=null} [sender=NodeB-52644]
09:29:51,062 TRACE (testng-DistSyncCacheStoreNotSharedTest:) [DummyInMemoryCacheStore] Clear store
09:29:51,062 DEBUG (testng-DistSyncCacheStoreNotSharedTest:) [TestingUtil] Cleaning data for cache 'dist' on a cache manager at address NodeC-33167
09:29:51,065 DEBUG (testng-DistSyncCacheStoreNotSharedTest:) [TestingUtil] removeInMemoryData(): dataContainerBefore == []
09:29:51,062 TRACE (OOB-1,ISPN,NodeC-33167:dist) [ReadCommittedEntry] Updating entry (key=k2 removed=false valid=true changed=true created=false value=value2]
09:29:51,065 TRACE (OOB-1,ISPN,NodeC-33167:dist) [EntryWrappingInterceptor] Committed entry ReadCommittedEntry(64d90a46){key=k2, value=value2, oldValue=null, isCreated=false, isChanged=false, isRemoved=false, isValid=true}
09:29:51,065 DEBUG (testng-DistSyncCacheStoreNotSharedTest:) [TestingUtil] removeInMemoryData(): dataContainerAfter == []
{noformat}
--
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, 3 months
[JBoss JIRA] (ISPN-2553) JBossMarshaller can be used before properly initialized
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-2553?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-2553:
-----------------------------------------------
Radim Vansa <rvansa(a)redhat.com> made a comment on [bug 880528|https://bugzilla.redhat.com/show_bug.cgi?id=880528]
I will try it, thanks.
> JBossMarshaller can be used before properly initialized
> -------------------------------------------------------
>
> Key: ISPN-2553
> URL: https://issues.jboss.org/browse/ISPN-2553
> Project: Infinispan
> Issue Type: Bug
> Components: Marshalling
> Affects Versions: 5.2.0.Beta4
> Reporter: Radim Vansa
> Assignee: Galder Zamarreño
> Fix For: 5.2.0.Beta6
>
>
> The {{JBossMarshaller}} can be used before its {{start()}} method is called. I've noticed that with replicated cache without transactions, an OOB thread can start demarshalling {{SingleRpcCommand}} in {{CacheRpcCommandExternalizer}} but when it tries to create a new unmarshaller (through {{AbstractJBossMarshaller.startObjectInput(...)}} and the {{marshallerTL.initialValue()}} the {{baseCfg}} configuration is not fully initialized yet and this results in creating marshallers in {{PerThreadInstanceHolder}} with {{objectTable == null}}. Then, objects are deserialized to {{null}}.
> I have verified this by inserting some log messages into constructors and start method:
> {code}
> 19:49:02,404 INFO [org.infinispan.marshall.jboss.AbstractJBossMarshaller] (pool-1-thread-1) Creating AbstractJBossMarshaller with org.jboss.marshalling.MarshallingConfiguration@1d296aa3: classExternalizerFactor
> y=<org.infinispan.marshall.jboss.SerializeWithExtFactory@a18024a> exceptionListener=<null> instanceCount=16 classCount=8 bufferSize=512 version=3
> 19:49:02,409 INFO [org.infinispan.marshall.jboss.AbstractJBossMarshaller] (pool-1-thread-1) Creating JBossMarshaller org.infinispan.marshall.jboss.JBossMarshaller@2e3e4d73
> 19:49:02,410 INFO [org.infinispan.marshall.jboss.AbstractJBossMarshaller] (pool-1-thread-1) Starting JBossMarshaller
> {code}
> and into the thread-local initialization and to {{getUnmarshaller()}} just before {{factory.createUnmarshaller}}:
> {code}
> 19:49:02,410 ERROR [org.infinispan.marshall.jboss.AbstractJBossMarshaller] (OOB-49,rvansa-22965) No object table in org.jboss.marshalling.MarshallingConfiguration@7c4ed0bc: classExternalizerFactory=<org.infinisp
> an.marshall.jboss.SerializeWithExtFactory@a18024a> exceptionListener=<null> instanceCount=16 classCount=8 bufferSize=512 version=3, base is org.jboss.marshalling.MarshallingConfiguration@1d296aa3: classExternali
> zerFactory=<org.infinispan.marshall.jboss.SerializeWithExtFactory@a18024a> exceptionListener=<null> instanceCount=16 classCount=8 bufferSize=512 version=3
> 19:49:02,453 ERROR [org.infinispan.marshall.jboss.AbstractJBossMarshaller] (OOB-49,rvansa-22965) Unmarshaller with cfg org.jboss.marshalling.MarshallingConfiguration@7c4ed0bc: classExternalizerFactory=<org.infin
> ispan.marshall.jboss.SerializeWithExtFactory@a18024a> exceptionListener=<null> instanceCount=16 classCount=8 bufferSize=512 version=3
> {code}
> See that the timestamps for {{start()}} and thread-local initialization are same, and the base configuration ({{baseCfg}}) does not have {{objectTable}} initialized.
--
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, 3 months
[JBoss JIRA] (ISPN-2605) single node cluster (local mode) can not start with IllegalStateException
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-2605?page=com.atlassian.jira.plugin.... ]
Dan Berindei resolved ISPN-2605.
--------------------------------
Resolution: Won't Fix
I'm marking this "Won't fix" because the cluster is behaving as designed: there is a <transport> element in the global configuration, so the cache manager is clustered and should create a JGroups channel.
> single node cluster (local mode) can not start with IllegalStateException
> -------------------------------------------------------------------------
>
> Key: ISPN-2605
> URL: https://issues.jboss.org/browse/ISPN-2605
> Project: Infinispan
> Issue Type: Bug
> Components: Core API
> Affects Versions: 5.1.4.FINAL
> Reporter: dex chen
> Assignee: Mircea Markus
>
> I have a single one node cluster configured a cache with cluster mode set to "local", and have several instances with the similar configurations without problem. However, one of system just can not start up.
>
> I made sure there is no duplicate names. Every time, I start the application and get the same error even after I change the cluster name in Infinispan.xml.
>
> I am using Infinisapn 5.1.4.Final for this.
> The jgroups channel better does not get started for "local" cluster.
> =================
>
> org.infinispan.manager.EmbeddedCacheManagerStartupException: org.infinispan.CacheException: Unable to invoke method public void org.infinispan.remoting.transport.jgroups.JGroupsTransport.start() on object of type JGroupsTransport
> at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:223)
> at org.infinispan.manager.DefaultCacheManager.wireCache(DefaultCacheManager.java:684)
> at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:649)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:549)
> ....
>
> Caused by: java.lang.IllegalStateException: cluster 'local_gw' is already connected to singleton transport: [dummy-1354557074615, dummy-1354557038904, dummy-1354557028675, dummy-1354557069508, dummy-1354557054249, dummy-1354557064426, dummy-1354557049152, dummy-1354557059345, dummy-1354557033791, dummy-1354557044023, local_gw]
> at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:909)
> at org.jgroups.JChannel.startStack(JChannel.java:841)
> at org.jgroups.JChannel.connect(JChannel.java:277)
> at org.jgroups.JChannel.connect(JChannel.java:261)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.startJGroupsChannelIfNeeded(JGroupsTransport.java:184)
> ... 21 more
--
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, 3 months
[JBoss JIRA] (ISPN-2605) single node cluster (local mode) can not start with IllegalStateException
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-2605?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-2605:
------------------------------------
If you configure a shared transport in JGroups, all the cache managers started from the same JVM have to use different cluster names. The error you're getting implies that you have two cache managers using the same 'local_gw' cluster name.
The transport component in Infinispan starts a new channel whenever the cache manager is started iff there is a <transport> element in the global configuration. So if this cache manager isn't meant to have any clustered caches, you should remove the <transport> element.
> single node cluster (local mode) can not start with IllegalStateException
> -------------------------------------------------------------------------
>
> Key: ISPN-2605
> URL: https://issues.jboss.org/browse/ISPN-2605
> Project: Infinispan
> Issue Type: Bug
> Components: Core API
> Affects Versions: 5.1.4.FINAL
> Reporter: dex chen
> Assignee: Mircea Markus
>
> I have a single one node cluster configured a cache with cluster mode set to "local", and have several instances with the similar configurations without problem. However, one of system just can not start up.
>
> I made sure there is no duplicate names. Every time, I start the application and get the same error even after I change the cluster name in Infinispan.xml.
>
> I am using Infinisapn 5.1.4.Final for this.
> The jgroups channel better does not get started for "local" cluster.
> =================
>
> org.infinispan.manager.EmbeddedCacheManagerStartupException: org.infinispan.CacheException: Unable to invoke method public void org.infinispan.remoting.transport.jgroups.JGroupsTransport.start() on object of type JGroupsTransport
> at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:223)
> at org.infinispan.manager.DefaultCacheManager.wireCache(DefaultCacheManager.java:684)
> at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:649)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:549)
> ....
>
> Caused by: java.lang.IllegalStateException: cluster 'local_gw' is already connected to singleton transport: [dummy-1354557074615, dummy-1354557038904, dummy-1354557028675, dummy-1354557069508, dummy-1354557054249, dummy-1354557064426, dummy-1354557049152, dummy-1354557059345, dummy-1354557033791, dummy-1354557044023, local_gw]
> at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:909)
> at org.jgroups.JChannel.startStack(JChannel.java:841)
> at org.jgroups.JChannel.connect(JChannel.java:277)
> at org.jgroups.JChannel.connect(JChannel.java:261)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.startJGroupsChannelIfNeeded(JGroupsTransport.java:184)
> ... 21 more
--
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, 3 months