[JBoss JIRA] (ISPN-4504) Topology id is not properly set on ClusteredGetCommands
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-4504?page=com.atlassian.jira.plugin.... ]
Dan Berindei edited comment on ISPN-4504 at 7/11/14 10:54 AM:
--------------------------------------------------------------
It turns out scenarios 5 and 7 should not be valid. I've rewritten the summary in RemoteGetDuringStateTransferTest, I think the new look makes it clear when we expect the originator to retry:
T = initial topology, T1 = rebalance started but we have no data yet, T2 = rebalance finished
| scenario | old scenario | first request | process request 1 | receive response 1 | retry | process request 2 | receive response 2 |
| 010 | 1 | T0 | 1:T1 | T0 | N | | |
| 011 | 2 | T0 | 1:T1 | T1 | N | | |
| [1] | | T0 | 1:T1 | T2 | N | | |
| [2] | | T0 | 1:T2 | T0 | N/A | | |
| [3] | | T0 | 1:T2 | T1 | Y | 2:T0 | N/A |
| 021_11 | 4 | T0 | 1:T2 | T1 | Y | 2:T1 | T1 |
| [1] | 4 | T0 | 1:T2 | T1 | Y | 2:T1 | T2 |
| 021_21 | 4.1 | T0 | 1:T2 | T1 | Y | 2:T2 | T1 |
| [1] | 4.1 | T0 | 1:T2 | T1 | Y | 2:T2 | T2 |
| [4] | 5 | T0 | 1:T2 | T2 | Y | 2:T1 | N/A |
| 022_22 | 5.1 | T0 | 1:T2 | T2 | Y | 2:T2 | T2 |
| 111 | 3 | T1 | 1:T1 | T1 | N | | |
| [1] | | T1 | 1:T1 | T2 | N | | |
| 121_11 | 6 | T1 | 1:T2 | T1 | Y | 2:T1 | T1 |
| [1] | | T1 | 1:T2 | T1 | Y | 2:T1 | T2 |
| 121_21 | 6.1 | T1 | 1:T2 | T1 | Y | 2:T2 | T1 |
| [1] | 6.1 | T1 | 1:T2 | T1 | Y | 2:T2 | T1 |
| [4] | 7 | T1 | 1:T2 | T2 | Y | 2:T1 | N/A |
| 122_22 | 7.1 | T1 | 1:T2 | T2 | Y | 2:T2 | T2 |
[1] too similar to the previous scenario
[2] impossible because we can't have T0 on one node and T2 on another node at the same time
[3] impossible because the 2nd request would block for until the target installs T1
[4] impossible because the 2nd request would block for until the target installs T2
I'm also thinking of adding a separate test with non-existent keys, something like this:
| scenario | first request | process request 1 | receive response 1 | retry | process request 2 | receive response 2 |
| 010 | T0 | 1:T1 | T0 | N | | |
| 011_11 | T0 | 1:T1 | T1 | Y | 2:T1 | T1 |
| [4] | T0 | 1:T1 | T2 | Y | 2:T1 | N/A |
| 011_22 | T0 | 1:T1 | T2 | Y | 2:T2 | T2 |
| [2] | T0 | 1:T2 | T0 | N/A | | |
| [3] | T0 | 1:T2 | T1 | Y | 2:T0 | N/A |
| 021_11 | T0 | 1:T2 | T1 | Y | 2:T1 | T1 |
| [1] | T0 | 1:T2 | T1 | Y | 2:T1 | T2 |
| 021_21 | T0 | 1:T2 | T1 | Y | 2:T2 | T1 |
| [1] | T0 | 1:T2 | T1 | Y | 2:T2 | T2 |
| [4] | T0 | 1:T2 | T2 | Y | 2:T1 | N/A |
| 022_22 | T0 | 1:T2 | T2 | Y | 2:T2 | T2 |
| 111 | T1 | 1:T1 | T1 | N | | |
| [4] | T1 | 1:T1 | T2 | Y | 2:T1 | N/A |
| 112_21 | T1 | 1:T1 | T2 | Y | 2:T2 | T1 |
| [1] | T1 | 1:T1 | T2 | Y | 2:T2 | T2 |
| 121_11 | T1 | 1:T2 | T1 | Y | 2:T1 | T1 |
| [1] | T1 | 1:T2 | T1 | Y | 2:T1 | T2 |
| 121_22 | T1 | 1:T2 | T1 | Y | 2:T2 | T2 |
| [4] | T1 | 1:T2 | T2 | Y | 2:T1 | N/A |
| 122_22 | T1 | 1:T2 | T2 | Y | 2:T2 | T2 |
was (Author: dan.berindei):
It turns out scenarios 5 and 7 should not be valid. I've rewritten the summary in RemoteGetDuringStateTransferTest, I think the new look makes it clear when we expect the originator to retry:
T = initial topology, T1 = rebalance started but we have no data yet, T2 = rebalance finished
| scenario | old scenario | first request | process request 1 | receive response 1 | retry | process request 2 | receive response 2 |
| 010 | 1 | T0 | 1:T1 | T0 | N | | |
| 011 | 2 | T0 | 1:T1 | T1 | N | | |
| [1] | | T0 | 1:T1 | T2 | N | | |
| [2] | | T0 | 1:T2 | T0 | N/A | | |
| [3] | | T0 | 1:T2 | T1 | Y | 2:T0 | N/A |
| 021_11 | 4 | T0 | 1:T2 | T1 | Y | 2:T1 | T1 |
| [1] | 4 | T0 | 1:T2 | T1 | Y | 2:T1 | T2 |
| 021_21 | 4.1 | T0 | 1:T2 | T1 | Y | 2:T2 | T1 |
| [1] | 4.1 | T0 | 1:T2 | T1 | Y | 2:T2 | T2 |
| [4] | 5 | T0 | 1:T2 | T2 | Y | 2:T1 | N/A |
| 022_22 | 5.1 | T0 | 1:T2 | T2 | Y | 2:T2 | T2 |
| 111 | 3 | T1 | 1:T1 | T1 | N | | |
| [1] | | T1 | 1:T1 | T2 | N | | |
| 121_11 | 6.1 | T1 | 1:T2 | T1 | Y | 2:T1 | T1 |
| [1] | | T1 | 1:T2 | T1 | Y | 2:T1 | T2 |
| 121_22 | 6 | T1 | 1:T2 | T1 | Y | 2:T2 | T2 |
| [4] | 7 | T1 | 1:T2 | T2 | Y | 2:T1 | N/A |
| 122_22 | 7.1 | T1 | 1:T2 | T2 | Y | 2:T2 | T2 |
[1] too similar to the previous scenario
[2] impossible because we can't have T0 on one node and T2 on another node at the same time
[3] impossible because the 2nd request would block for until the target installs T1
[4] impossible because the 2nd request would block for until the target installs T2
I'm also thinking of adding a separate test with non-existent keys, something like this:
| scenario | first request | process request 1 | receive response 1 | retry | process request 2 | receive response 2 |
| 010 | T0 | 1:T1 | T0 | N | | |
| 011_11 | T0 | 1:T1 | T1 | Y | 2:T1 | T1 |
| [4] | T0 | 1:T1 | T2 | Y | 2:T1 | N/A |
| 011_22 | T0 | 1:T1 | T2 | Y | 2:T2 | T2 |
| [2] | T0 | 1:T2 | T0 | N/A | | |
| [3] | T0 | 1:T2 | T1 | Y | 2:T0 | N/A |
| 021_11 | T0 | 1:T2 | T1 | Y | 2:T1 | T1 |
| [1] | T0 | 1:T2 | T1 | Y | 2:T1 | T2 |
| 021_21 | T0 | 1:T2 | T1 | Y | 2:T2 | T1 |
| [1] | T0 | 1:T2 | T1 | Y | 2:T2 | T2 |
| [4] | T0 | 1:T2 | T2 | Y | 2:T1 | N/A |
| 022_22 | T0 | 1:T2 | T2 | Y | 2:T2 | T2 |
| 111 | T1 | 1:T1 | T1 | N | | |
| [4] | T1 | 1:T1 | T2 | Y | 2:T1 | N/A |
| 112_22 | T1 | 1:T1 | T2 | Y | 2:T2 | T2 |
| 121_11 | T1 | 1:T2 | T1 | Y | 2:T1 | T1 |
| [1] | T1 | 1:T2 | T1 | Y | 2:T1 | T2 |
| 121_22 | T1 | 1:T2 | T1 | Y | 2:T2 | T2 |
| [4] | T1 | 1:T2 | T2 | Y | 2:T1 | N/A |
| 122_22 | T1 | 1:T2 | T2 | Y | 2:T2 | T2 |
> Topology id is not properly set on ClusteredGetCommands
> -------------------------------------------------------
>
> Key: ISPN-4504
> URL: https://issues.jboss.org/browse/ISPN-4504
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Core
> Affects Versions: 7.0.0.Alpha4
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 7.0.0.Alpha5
>
>
> Because the topology id is not properly set on ClusteredGetCommands, they don't wait for the sender's topology to be installed on the target.
> I have tried to fix this while implementing a fix for ISPN-4503. My solution caused 2 failures in RemoteGetDuringStateTransferTest, scenarios 5 and 7::
> | sc | currentTopologyId | currentTopologyId + 1 (rebalance) | currentTopologyId + 2 (finish) |
> | 5 | 0:remoteGet | 2:sendReply | 0:receiveReply, 1:sendReply |
> | 7 | | 0:remoteGet, 2: sendReply | 0:receiveReply, 1:sendReply |
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 4 months
[JBoss JIRA] (ISPN-4507) JniLevelDBStoreFunctionalTest fails on RHEL, ClassNotFoundException: org.fusesource.leveldbjni.JniDBFactory
by Vitalii Chepeliuk (JIRA)
[ https://issues.jboss.org/browse/ISPN-4507?page=com.atlassian.jira.plugin.... ]
Vitalii Chepeliuk updated ISPN-4507:
------------------------------------
Summary: JniLevelDBStoreFunctionalTest fails on RHEL, ClassNotFoundException: org.fusesource.leveldbjni.JniDBFactory (was: JniLevelDBStoreFunctionalTest fails on RHEL, OsgiClassLoader can not load org.fusesource.leveldbjni.JniDBFactory class)
> JniLevelDBStoreFunctionalTest fails on RHEL, ClassNotFoundException: org.fusesource.leveldbjni.JniDBFactory
> -----------------------------------------------------------------------------------------------------------
>
> Key: ISPN-4507
> URL: https://issues.jboss.org/browse/ISPN-4507
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 7.0.0.Alpha4
> Environment: RHEL5, RHEL6
> Reporter: Vitalii Chepeliuk
> Assignee: Mircea Markus
> Labels: testsuite_stability
> Attachments: JniLevelDBStoreFunctionalTest.log.zip
>
>
> {noformat}
> org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.persistence.manager.PersistenceManagerImpl.start() on object of type PersistenceManagerImpl
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:170)
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869)
> at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638)
> at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627)
> at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530)
> at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:216)
> at org.infinispan.CacheImpl.start(CacheImpl.java:696)
> at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:575)
> at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:530)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:410)
> at org.infinispan.persistence.BaseStoreFunctionalTest.cleanup(BaseStoreFunctionalTest.java:64)
> 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.invokeConfigurationMethod(Invoker.java:564)
> at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:213)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:786)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
> at org.testng.TestRunner.privateRun(TestRunner.java:767)
> at org.testng.TestRunner.run(TestRunner.java:617)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java: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)
> Caused by: org.infinispan.commons.CacheException: Unable to start cache loaders
> at org.infinispan.persistence.manager.PersistenceManagerImpl.start(PersistenceManagerImpl.java:155)
> at sun.reflect.GeneratedMethodAccessor59.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168)
> ... 32 more
> Caused by: org.infinispan.commons.CacheConfigurationException: Unable to instantiate class org.fusesource.leveldbjni.JniDBFactory
> at org.infinispan.commons.util.Util.loadClass(Util.java:85)
> at org.infinispan.commons.util.Util.getInstance(Util.java:223)
> at org.infinispan.persistence.leveldb.LevelDBStore.newDbFactory(LevelDBStore.java:76)
> at org.infinispan.persistence.leveldb.LevelDBStore.init(LevelDBStore.java:59)
> at org.infinispan.persistence.manager.PersistenceManagerImpl.createLoadersAndWriters(PersistenceManagerImpl.java:579)
> at org.infinispan.persistence.manager.PersistenceManagerImpl.start(PersistenceManagerImpl.java:113)
> ... 36 more
> Caused by: java.lang.ClassNotFoundException: Could not load requested class : org.fusesource.leveldbjni.JniDBFactory
> at org.infinispan.commons.util.OsgiClassLoader.findClass(OsgiClassLoader.java:89)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:270)
> at org.infinispan.commons.util.Util.loadClassStrict(Util.java:139)
> at org.infinispan.commons.util.Util.loadClass(Util.java:83)
> ... 41 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 4 months
[JBoss JIRA] (ISPN-4507) JniLevelDBStoreFunctionalTest fails on RHEL, OsgiClassLoader can not load org.fusesource.leveldbjni.JniDBFactory class
by Vitalii Chepeliuk (JIRA)
[ https://issues.jboss.org/browse/ISPN-4507?page=com.atlassian.jira.plugin.... ]
Vitalii Chepeliuk updated ISPN-4507:
------------------------------------
Summary: JniLevelDBStoreFunctionalTest fails on RHEL, OsgiClassLoader can not load org.fusesource.leveldbjni.JniDBFactory class (was: JniLevelDBStoreFunctionalTest fail on RHEL)
> JniLevelDBStoreFunctionalTest fails on RHEL, OsgiClassLoader can not load org.fusesource.leveldbjni.JniDBFactory class
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-4507
> URL: https://issues.jboss.org/browse/ISPN-4507
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 7.0.0.Alpha4
> Environment: RHEL5, RHEL6
> Reporter: Vitalii Chepeliuk
> Assignee: Mircea Markus
> Labels: testsuite_stability
> Attachments: JniLevelDBStoreFunctionalTest.log.zip
>
>
> {noformat}
> org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.persistence.manager.PersistenceManagerImpl.start() on object of type PersistenceManagerImpl
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:170)
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869)
> at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638)
> at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627)
> at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530)
> at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:216)
> at org.infinispan.CacheImpl.start(CacheImpl.java:696)
> at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:575)
> at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:530)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:410)
> at org.infinispan.persistence.BaseStoreFunctionalTest.cleanup(BaseStoreFunctionalTest.java:64)
> 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.invokeConfigurationMethod(Invoker.java:564)
> at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:213)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:786)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
> at org.testng.TestRunner.privateRun(TestRunner.java:767)
> at org.testng.TestRunner.run(TestRunner.java:617)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java: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)
> Caused by: org.infinispan.commons.CacheException: Unable to start cache loaders
> at org.infinispan.persistence.manager.PersistenceManagerImpl.start(PersistenceManagerImpl.java:155)
> at sun.reflect.GeneratedMethodAccessor59.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168)
> ... 32 more
> Caused by: org.infinispan.commons.CacheConfigurationException: Unable to instantiate class org.fusesource.leveldbjni.JniDBFactory
> at org.infinispan.commons.util.Util.loadClass(Util.java:85)
> at org.infinispan.commons.util.Util.getInstance(Util.java:223)
> at org.infinispan.persistence.leveldb.LevelDBStore.newDbFactory(LevelDBStore.java:76)
> at org.infinispan.persistence.leveldb.LevelDBStore.init(LevelDBStore.java:59)
> at org.infinispan.persistence.manager.PersistenceManagerImpl.createLoadersAndWriters(PersistenceManagerImpl.java:579)
> at org.infinispan.persistence.manager.PersistenceManagerImpl.start(PersistenceManagerImpl.java:113)
> ... 36 more
> Caused by: java.lang.ClassNotFoundException: Could not load requested class : org.fusesource.leveldbjni.JniDBFactory
> at org.infinispan.commons.util.OsgiClassLoader.findClass(OsgiClassLoader.java:89)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:270)
> at org.infinispan.commons.util.Util.loadClassStrict(Util.java:139)
> at org.infinispan.commons.util.Util.loadClass(Util.java:83)
> ... 41 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 4 months
[JBoss JIRA] (ISPN-4504) Topology id is not properly set on ClusteredGetCommands
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-4504?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-4504:
------------------------------------
It turns out scenarios 5 and 7 should not be valid. I've rewritten the summary in RemoteGetDuringStateTransferTest, I think the new look makes it clear when we expect the originator to retry:
T = initial topology, T1 = rebalance started but we have no data yet, T1.5 rebalance started and we have data, T2 = rebalance finished
| scenario | old scenario | first request | process request 1 | receive response 1 | retry | process request 2 | receive response 2 |
| 010 | 1 | T0 | 1:T1 | T0 | N | | |
| 011 | 2 | T0 | 1:T1 | T1 | N | | |
| [1] | | T0 | 1:T1 | T2 | N | | |
| [2] | | T0 | 1:T2 | T0 | N/A | | |
| [3] | | T0 | 1:T2 | T1 | Y | 2:T0 | N/A |
| 021_11 | 4 | T0 | 1:T2 | T1 | Y | 2:T1 | T1 |
| [1] | 4 | T0 | 1:T2 | T1 | Y | 2:T1 | T2 |
| 021_21 | 4.1 | T0 | 1:T2 | T1 | Y | 2:T2 | T1 |
| [1] | 4.1 | T0 | 1:T2 | T1 | Y | 2:T2 | T2 |
| [4] | 5 | T0 | 1:T2 | T2 | Y | 2:T1 | N/A |
| 022_22 | 5.1 | T0 | 1:T2 | T2 | Y | 2:T2 | T2 |
| 111 | 3 | T1 | 1:T1 | T1 | N | | |
| [1] | | T1 | 1:T1 | T2 | N | | |
| 121_11 | 6.1 | T1 | 1:T2 | T1 | Y | 2:T1 | T1 |
| [1] | | T1 | 1:T2 | T1 | Y | 2:T1 | T2 |
| 121_22 | 6 | T1 | 1:T2 | T1 | Y | 2:T2 | T2 |
| [4] | 7 | T1 | 1:T2 | T2 | Y | 2:T1 | N/A |
| 122_22 | 7.1 | T1 | 1:T2 | T2 | Y | 2:T2 | T2 |
[1] too similar to the previous scenario
[2] impossible because we can't have T0 on one node and T2 on another node at the same time
[3] impossible because the 2nd request would block for until the target installs T1
[4] impossible because the 2nd request would block for until the target installs T2
I'm also thinking of adding a separate test with non-existent keys, something like this:
| scenario | first request | process request 1 | receive response 1 | retry | process request 2 | receive response 2 |
| 010 | T0 | 1:T1 | T0 | N | | |
| 011_11 | T0 | 1:T1 | T1 | Y | 2:T1 | T1 |
| [4] | T0 | 1:T1 | T2 | Y | 2:T1 | N/A |
| 011_22 | T0 | 1:T1 | T2 | Y | 2:T2 | T2 |
| [2] | T0 | 1:T2 | T0 | N/A | | |
| [3] | T0 | 1:T2 | T1 | Y | 2:T0 | N/A |
| 021_11 | T0 | 1:T2 | T1 | Y | 2:T1 | T1 |
| [1] | T0 | 1:T2 | T1 | Y | 2:T1 | T2 |
| 021_21 | T0 | 1:T2 | T1 | Y | 2:T2 | T1 |
| [1] | T0 | 1:T2 | T1 | Y | 2:T2 | T2 |
| [4] | T0 | 1:T2 | T2 | Y | 2:T1 | N/A |
| 022_22 | T0 | 1:T2 | T2 | Y | 2:T2 | T2 |
| 111 | T1 | 1:T1 | T1 | N | | |
| [4] | T1 | 1:T1 | T2 | Y | 2:T1 | N/A |
| 112_22 | T1 | 1:T1 | T2 | Y | 2:T2 | T2 |
| 121_11 | T1 | 1:T2 | T1 | Y | 2:T1 | T1 |
| [1] | T1 | 1:T2 | T1 | Y | 2:T1 | T2 |
| 121_22 | T1 | 1:T2 | T1 | Y | 2:T2 | T2 |
| [4] | T1 | 1:T2 | T2 | Y | 2:T1 | N/A |
| 122_22 | T1 | 1:T2 | T2 | Y | 2:T2 | T2 |
> Topology id is not properly set on ClusteredGetCommands
> -------------------------------------------------------
>
> Key: ISPN-4504
> URL: https://issues.jboss.org/browse/ISPN-4504
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Core
> Affects Versions: 7.0.0.Alpha4
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 7.0.0.Alpha5
>
>
> Because the topology id is not properly set on ClusteredGetCommands, they don't wait for the sender's topology to be installed on the target.
> I have tried to fix this while implementing a fix for ISPN-4503. My solution caused 2 failures in RemoteGetDuringStateTransferTest, scenarios 5 and 7::
> | sc | currentTopologyId | currentTopologyId + 1 (rebalance) | currentTopologyId + 2 (finish) |
> | 5 | 0:remoteGet | 2:sendReply | 0:receiveReply, 1:sendReply |
> | 7 | | 0:remoteGet, 2: sendReply | 0:receiveReply, 1:sendReply |
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 4 months
[JBoss JIRA] (ISPN-4504) Topology id is not properly set on ClusteredGetCommands
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-4504?page=com.atlassian.jira.plugin.... ]
Dan Berindei edited comment on ISPN-4504 at 7/11/14 10:42 AM:
--------------------------------------------------------------
It turns out scenarios 5 and 7 should not be valid. I've rewritten the summary in RemoteGetDuringStateTransferTest, I think the new look makes it clear when we expect the originator to retry:
T = initial topology, T1 = rebalance started but we have no data yet, T2 = rebalance finished
| scenario | old scenario | first request | process request 1 | receive response 1 | retry | process request 2 | receive response 2 |
| 010 | 1 | T0 | 1:T1 | T0 | N | | |
| 011 | 2 | T0 | 1:T1 | T1 | N | | |
| [1] | | T0 | 1:T1 | T2 | N | | |
| [2] | | T0 | 1:T2 | T0 | N/A | | |
| [3] | | T0 | 1:T2 | T1 | Y | 2:T0 | N/A |
| 021_11 | 4 | T0 | 1:T2 | T1 | Y | 2:T1 | T1 |
| [1] | 4 | T0 | 1:T2 | T1 | Y | 2:T1 | T2 |
| 021_21 | 4.1 | T0 | 1:T2 | T1 | Y | 2:T2 | T1 |
| [1] | 4.1 | T0 | 1:T2 | T1 | Y | 2:T2 | T2 |
| [4] | 5 | T0 | 1:T2 | T2 | Y | 2:T1 | N/A |
| 022_22 | 5.1 | T0 | 1:T2 | T2 | Y | 2:T2 | T2 |
| 111 | 3 | T1 | 1:T1 | T1 | N | | |
| [1] | | T1 | 1:T1 | T2 | N | | |
| 121_11 | 6.1 | T1 | 1:T2 | T1 | Y | 2:T1 | T1 |
| [1] | | T1 | 1:T2 | T1 | Y | 2:T1 | T2 |
| 121_22 | 6 | T1 | 1:T2 | T1 | Y | 2:T2 | T2 |
| [4] | 7 | T1 | 1:T2 | T2 | Y | 2:T1 | N/A |
| 122_22 | 7.1 | T1 | 1:T2 | T2 | Y | 2:T2 | T2 |
[1] too similar to the previous scenario
[2] impossible because we can't have T0 on one node and T2 on another node at the same time
[3] impossible because the 2nd request would block for until the target installs T1
[4] impossible because the 2nd request would block for until the target installs T2
I'm also thinking of adding a separate test with non-existent keys, something like this:
| scenario | first request | process request 1 | receive response 1 | retry | process request 2 | receive response 2 |
| 010 | T0 | 1:T1 | T0 | N | | |
| 011_11 | T0 | 1:T1 | T1 | Y | 2:T1 | T1 |
| [4] | T0 | 1:T1 | T2 | Y | 2:T1 | N/A |
| 011_22 | T0 | 1:T1 | T2 | Y | 2:T2 | T2 |
| [2] | T0 | 1:T2 | T0 | N/A | | |
| [3] | T0 | 1:T2 | T1 | Y | 2:T0 | N/A |
| 021_11 | T0 | 1:T2 | T1 | Y | 2:T1 | T1 |
| [1] | T0 | 1:T2 | T1 | Y | 2:T1 | T2 |
| 021_21 | T0 | 1:T2 | T1 | Y | 2:T2 | T1 |
| [1] | T0 | 1:T2 | T1 | Y | 2:T2 | T2 |
| [4] | T0 | 1:T2 | T2 | Y | 2:T1 | N/A |
| 022_22 | T0 | 1:T2 | T2 | Y | 2:T2 | T2 |
| 111 | T1 | 1:T1 | T1 | N | | |
| [4] | T1 | 1:T1 | T2 | Y | 2:T1 | N/A |
| 112_22 | T1 | 1:T1 | T2 | Y | 2:T2 | T2 |
| 121_11 | T1 | 1:T2 | T1 | Y | 2:T1 | T1 |
| [1] | T1 | 1:T2 | T1 | Y | 2:T1 | T2 |
| 121_22 | T1 | 1:T2 | T1 | Y | 2:T2 | T2 |
| [4] | T1 | 1:T2 | T2 | Y | 2:T1 | N/A |
| 122_22 | T1 | 1:T2 | T2 | Y | 2:T2 | T2 |
was (Author: dan.berindei):
It turns out scenarios 5 and 7 should not be valid. I've rewritten the summary in RemoteGetDuringStateTransferTest, I think the new look makes it clear when we expect the originator to retry:
T = initial topology, T1 = rebalance started but we have no data yet, T1.5 rebalance started and we have data, T2 = rebalance finished
| scenario | old scenario | first request | process request 1 | receive response 1 | retry | process request 2 | receive response 2 |
| 010 | 1 | T0 | 1:T1 | T0 | N | | |
| 011 | 2 | T0 | 1:T1 | T1 | N | | |
| [1] | | T0 | 1:T1 | T2 | N | | |
| [2] | | T0 | 1:T2 | T0 | N/A | | |
| [3] | | T0 | 1:T2 | T1 | Y | 2:T0 | N/A |
| 021_11 | 4 | T0 | 1:T2 | T1 | Y | 2:T1 | T1 |
| [1] | 4 | T0 | 1:T2 | T1 | Y | 2:T1 | T2 |
| 021_21 | 4.1 | T0 | 1:T2 | T1 | Y | 2:T2 | T1 |
| [1] | 4.1 | T0 | 1:T2 | T1 | Y | 2:T2 | T2 |
| [4] | 5 | T0 | 1:T2 | T2 | Y | 2:T1 | N/A |
| 022_22 | 5.1 | T0 | 1:T2 | T2 | Y | 2:T2 | T2 |
| 111 | 3 | T1 | 1:T1 | T1 | N | | |
| [1] | | T1 | 1:T1 | T2 | N | | |
| 121_11 | 6.1 | T1 | 1:T2 | T1 | Y | 2:T1 | T1 |
| [1] | | T1 | 1:T2 | T1 | Y | 2:T1 | T2 |
| 121_22 | 6 | T1 | 1:T2 | T1 | Y | 2:T2 | T2 |
| [4] | 7 | T1 | 1:T2 | T2 | Y | 2:T1 | N/A |
| 122_22 | 7.1 | T1 | 1:T2 | T2 | Y | 2:T2 | T2 |
[1] too similar to the previous scenario
[2] impossible because we can't have T0 on one node and T2 on another node at the same time
[3] impossible because the 2nd request would block for until the target installs T1
[4] impossible because the 2nd request would block for until the target installs T2
I'm also thinking of adding a separate test with non-existent keys, something like this:
| scenario | first request | process request 1 | receive response 1 | retry | process request 2 | receive response 2 |
| 010 | T0 | 1:T1 | T0 | N | | |
| 011_11 | T0 | 1:T1 | T1 | Y | 2:T1 | T1 |
| [4] | T0 | 1:T1 | T2 | Y | 2:T1 | N/A |
| 011_22 | T0 | 1:T1 | T2 | Y | 2:T2 | T2 |
| [2] | T0 | 1:T2 | T0 | N/A | | |
| [3] | T0 | 1:T2 | T1 | Y | 2:T0 | N/A |
| 021_11 | T0 | 1:T2 | T1 | Y | 2:T1 | T1 |
| [1] | T0 | 1:T2 | T1 | Y | 2:T1 | T2 |
| 021_21 | T0 | 1:T2 | T1 | Y | 2:T2 | T1 |
| [1] | T0 | 1:T2 | T1 | Y | 2:T2 | T2 |
| [4] | T0 | 1:T2 | T2 | Y | 2:T1 | N/A |
| 022_22 | T0 | 1:T2 | T2 | Y | 2:T2 | T2 |
| 111 | T1 | 1:T1 | T1 | N | | |
| [4] | T1 | 1:T1 | T2 | Y | 2:T1 | N/A |
| 112_22 | T1 | 1:T1 | T2 | Y | 2:T2 | T2 |
| 121_11 | T1 | 1:T2 | T1 | Y | 2:T1 | T1 |
| [1] | T1 | 1:T2 | T1 | Y | 2:T1 | T2 |
| 121_22 | T1 | 1:T2 | T1 | Y | 2:T2 | T2 |
| [4] | T1 | 1:T2 | T2 | Y | 2:T1 | N/A |
| 122_22 | T1 | 1:T2 | T2 | Y | 2:T2 | T2 |
> Topology id is not properly set on ClusteredGetCommands
> -------------------------------------------------------
>
> Key: ISPN-4504
> URL: https://issues.jboss.org/browse/ISPN-4504
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Core
> Affects Versions: 7.0.0.Alpha4
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 7.0.0.Alpha5
>
>
> Because the topology id is not properly set on ClusteredGetCommands, they don't wait for the sender's topology to be installed on the target.
> I have tried to fix this while implementing a fix for ISPN-4503. My solution caused 2 failures in RemoteGetDuringStateTransferTest, scenarios 5 and 7::
> | sc | currentTopologyId | currentTopologyId + 1 (rebalance) | currentTopologyId + 2 (finish) |
> | 5 | 0:remoteGet | 2:sendReply | 0:receiveReply, 1:sendReply |
> | 7 | | 0:remoteGet, 2: sendReply | 0:receiveReply, 1:sendReply |
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 4 months
[JBoss JIRA] (ISPN-4460) Map-Reduce: Mapper sometimes receives null value
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4460?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4460:
-----------------------------------------------
Alan Field <afield(a)redhat.com> changed the Status of [bug 1116979|https://bugzilla.redhat.com/show_bug.cgi?id=1116979] from ON_QA to VERIFIED
> Map-Reduce: Mapper sometimes receives null value
> ------------------------------------------------
>
> Key: ISPN-4460
> URL: https://issues.jboss.org/browse/ISPN-4460
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.0.2.Final
> Reporter: Rich DiCroce
> Assignee: Vladimir Blagojevic
> Fix For: 7.0.0.Alpha5
>
>
> I have a Mapper with the following map method:
> {code}
> public void map(EndpointAddress key, EndpointInfo value, Collector<Address, Integer> collector) {
> // TODO debugging, remove this
> if (value == null) {
> System.out.println("value is null! WTF");
> }
> if (collector == null) {
> System.out.println("collector is null! OMGWTFBBQ");
> }
> collector.emit(value.getConnectedGP(), 1);
> }
> {code}
> Null checks were added because I am sometimes seeing a NullPointerException on the last line. Console output is below. I cannot reliably reproduce this problem. It's clearly a race condition of some kind. The cache that is being queried has keys being added/removed all the time.
> {noformat}
> 14:05:30,020 INFO [stdout] (transport-thread-18) value is null! WTF
> 14:05:30,022 ERROR [com.sg.song.nms.ispn.DataGatherer] (EJB default - 3) GP table column query failed: java.util.concurrent.ExecutionException: org.infinispan.commons.CacheException: java.util.concurrent.ExecutionException: java.lang.NullPointerException
> at org.infinispan.distexec.mapreduce.MapReduceTask$MapReduceTaskFuture.get(MapReduceTask.java:762) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at com.sg.song.nms.ispn.DataGatherer.queryCurrentGPStatistics(DataGatherer.java:116) [classes:]
> at sun.reflect.GeneratedMethodAccessor41.invoke(Unknown Source) [:1.7.0_45]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_45]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_45]
> at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
> at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:61)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:407)
> at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82) [wildfly-weld-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:95) [wildfly-weld-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:61)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
> at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:61)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.tx.EjbBMTInterceptor.handleInvocation(EjbBMTInterceptor.java:104) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.ejb3.tx.BMTInterceptor.processInvocation(BMTInterceptor.java:56) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:407)
> at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:55) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
> at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83) [wildfly-weld-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) [wildfly-ee-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.singleton.SingletonComponentInstanceAssociationInterceptor.processInvocation(SingletonComponentInstanceAssociationInterceptor.java:52) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:95) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:326)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:448)
> at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:326)
> at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ejb3.timerservice.TimedObjectInvokerImpl.callTimeout(TimedObjectInvokerImpl.java:104) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.ejb3.timerservice.task.CalendarTimerTask.callTimeout(CalendarTimerTask.java:61) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.ejb3.timerservice.task.TimerTask.run(TimerTask.java:168) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_45]
> at java.util.concurrent.FutureTask.run(FutureTask.java:262) [rt.jar:1.7.0_45]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> Caused by: org.infinispan.commons.CacheException: java.util.concurrent.ExecutionException: java.lang.NullPointerException
> at org.infinispan.distexec.mapreduce.MapReduceTask.execute(MapReduceTask.java:348) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.distexec.mapreduce.MapReduceTask.execute(MapReduceTask.java:634) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.distexec.mapreduce.MapReduceTask$3.call(MapReduceTask.java:652) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.distexec.mapreduce.MapReduceTask$MapReduceTaskFuture.get(MapReduceTask.java:760) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> ... 62 more
> Caused by: java.util.concurrent.ExecutionException: java.lang.NullPointerException
> at java.util.concurrent.FutureTask.report(FutureTask.java:122) [rt.jar:1.7.0_45]
> at java.util.concurrent.FutureTask.get(FutureTask.java:188) [rt.jar:1.7.0_45]
> at org.infinispan.distexec.mapreduce.MapReduceTask$TaskPart.get(MapReduceTask.java:845) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.distexec.mapreduce.MapReduceTask.executeMapPhase(MapReduceTask.java:439) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.distexec.mapreduce.MapReduceTask.execute(MapReduceTask.java:342) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> ... 65 more
> Caused by: java.lang.NullPointerException
> at com.sgi.song.gp.protocol.SONGv1.cluster.query.RegistrationsByGPMapper.map(RegistrationsByGPMapper.java:26) [gp-ispn-shared-1.0.0-SNAPSHOT.jar:]
> at com.sgi.song.gp.protocol.SONGv1.cluster.query.RegistrationsByGPMapper.map(RegistrationsByGPMapper.java:1) [gp-ispn-shared-1.0.0-SNAPSHOT.jar:]
> at org.infinispan.distexec.mapreduce.MapReduceManagerImpl.map(MapReduceManagerImpl.java:181) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.distexec.mapreduce.MapReduceManagerImpl.mapAndCombineForDistributedReduction(MapReduceManagerImpl.java:96) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.distexec.mapreduce.MapReduceTask$MapTaskPart.invokeMapCombineLocally(MapReduceTask.java:967) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.distexec.mapreduce.MapReduceTask$MapTaskPart.access$200(MapReduceTask.java:894) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.distexec.mapreduce.MapReduceTask$MapTaskPart$1.call(MapReduceTask.java:916) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.distexec.mapreduce.MapReduceTask$MapTaskPart$1.call(MapReduceTask.java:912) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at java.util.concurrent.FutureTask.run(FutureTask.java:262) [rt.jar:1.7.0_45]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_45]
> at java.util.concurrent.FutureTask.run(FutureTask.java:262) [rt.jar:1.7.0_45]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 4 months