[JBoss JIRA] (ISPN-4468) HR client is not able to unmarshall custom class when using AS modules
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4468?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4468:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1168262|https://bugzilla.redhat.com/show_bug.cgi?id=1168262] from NEW to ASSIGNED
> HR client is not able to unmarshall custom class when using AS modules
> ----------------------------------------------------------------------
>
> Key: ISPN-4468
> URL: https://issues.jboss.org/browse/ISPN-4468
> Project: Infinispan
> Issue Type: Bug
> Components: Marshalling, Remote Protocols
> Reporter: Vojtech Juranek
> Assignee: Galder Zamarreño
>
> When using HR client in JBoss and use JBoss modules for HR client, storing custom objects into remote cache works, however when custom objects is read back from remote cache, it fails as {{ClassNotFoundException}}:
> {noformat}
> testPutGetCustomObject(com.jboss.datagrid.test.hotrod.HotRodRemoteCacheIT) Time elapsed: 1.749 sec <<< ERROR!
> org.infinispan.client.hotrod.exceptions.HotRodClientException: Unable to unmarshall byte stream
> at org.infinispan.client.hotrod.impl.RemoteCacheImpl.bytes2obj(RemoteCacheImpl.java:555)
> at org.infinispan.client.hotrod.impl.RemoteCacheImpl.get(RemoteCacheImpl.java:425)
> at org.infinispan.server.test.client.hotrod.AbstractRemoteCacheIT.testPutGetCustomObject(AbstractRemoteCacheIT.java:746)
> {noformat}
> [...]
> {noformat}
> Caused by: java.lang.ClassNotFoundException: org.infinispan.server.test.client.hotrod.AbstractRemoteCacheIT$Person from [Module "org.infinispan.commons:jdg-6.3" from local module loader @5cbf5bb7 (finder: local module finder @171e7af3 (roots: /opt/test_servers/jboss-eap-6.2.2/modules,/opt/test_servers/jboss-eap-6.2.2/modules/system/layers/base))]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:270)
> at org.jboss.marshalling.AbstractClassResolver.loadClass(AbstractClassResolver.java:131)
> at org.jboss.marshalling.AbstractClassResolver.resolveClass(AbstractClassResolver.java:112)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:943)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1239)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
> at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41)
> at org.infinispan.commons.marshall.jboss.AbstractJBossMarshaller.objectFromObjectStream(AbstractJBossMarshaller.java:135)
> at org.infinispan.commons.marshall.jboss.AbstractJBossMarshaller.objectFromByteBuffer(AbstractJBossMarshaller.java:113)
> at org.infinispan.commons.marshall.AbstractMarshaller.objectFromByteBuffer(AbstractMarshaller.java:82)
> at org.infinispan.client.hotrod.impl.RemoteCacheImpl.bytes2obj(RemoteCacheImpl.java:553)
> at org.infinispan.client.hotrod.impl.RemoteCacheImpl.get(RemoteCacheImpl.java:425)
> at org.infinispan.server.test.client.hotrod.AbstractRemoteCacheIT.testPutGetCustomObject(AbstractRemoteCacheIT.java:746)
> {noformat}
> Adding jar file with {{org.infinispan.server.test.client.hotrod.AbstractRemoteCacheIT$Person}} into jboss-deployment-structure as a module didn't helped.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
10 years, 1 month
[JBoss JIRA] (ISPN-4468) HR client is not able to unmarshall custom class when using AS modules
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4468?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated ISPN-4468:
------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1115090, https://bugzilla.redhat.com/show_bug.cgi?id=1168262 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1115090)
> HR client is not able to unmarshall custom class when using AS modules
> ----------------------------------------------------------------------
>
> Key: ISPN-4468
> URL: https://issues.jboss.org/browse/ISPN-4468
> Project: Infinispan
> Issue Type: Bug
> Components: Marshalling, Remote Protocols
> Reporter: Vojtech Juranek
> Assignee: Galder Zamarreño
>
> When using HR client in JBoss and use JBoss modules for HR client, storing custom objects into remote cache works, however when custom objects is read back from remote cache, it fails as {{ClassNotFoundException}}:
> {noformat}
> testPutGetCustomObject(com.jboss.datagrid.test.hotrod.HotRodRemoteCacheIT) Time elapsed: 1.749 sec <<< ERROR!
> org.infinispan.client.hotrod.exceptions.HotRodClientException: Unable to unmarshall byte stream
> at org.infinispan.client.hotrod.impl.RemoteCacheImpl.bytes2obj(RemoteCacheImpl.java:555)
> at org.infinispan.client.hotrod.impl.RemoteCacheImpl.get(RemoteCacheImpl.java:425)
> at org.infinispan.server.test.client.hotrod.AbstractRemoteCacheIT.testPutGetCustomObject(AbstractRemoteCacheIT.java:746)
> {noformat}
> [...]
> {noformat}
> Caused by: java.lang.ClassNotFoundException: org.infinispan.server.test.client.hotrod.AbstractRemoteCacheIT$Person from [Module "org.infinispan.commons:jdg-6.3" from local module loader @5cbf5bb7 (finder: local module finder @171e7af3 (roots: /opt/test_servers/jboss-eap-6.2.2/modules,/opt/test_servers/jboss-eap-6.2.2/modules/system/layers/base))]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:270)
> at org.jboss.marshalling.AbstractClassResolver.loadClass(AbstractClassResolver.java:131)
> at org.jboss.marshalling.AbstractClassResolver.resolveClass(AbstractClassResolver.java:112)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:943)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1239)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
> at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41)
> at org.infinispan.commons.marshall.jboss.AbstractJBossMarshaller.objectFromObjectStream(AbstractJBossMarshaller.java:135)
> at org.infinispan.commons.marshall.jboss.AbstractJBossMarshaller.objectFromByteBuffer(AbstractJBossMarshaller.java:113)
> at org.infinispan.commons.marshall.AbstractMarshaller.objectFromByteBuffer(AbstractMarshaller.java:82)
> at org.infinispan.client.hotrod.impl.RemoteCacheImpl.bytes2obj(RemoteCacheImpl.java:553)
> at org.infinispan.client.hotrod.impl.RemoteCacheImpl.get(RemoteCacheImpl.java:425)
> at org.infinispan.server.test.client.hotrod.AbstractRemoteCacheIT.testPutGetCustomObject(AbstractRemoteCacheIT.java:746)
> {noformat}
> Adding jar file with {{org.infinispan.server.test.client.hotrod.AbstractRemoteCacheIT$Person}} into jboss-deployment-structure as a module didn't helped.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
10 years, 1 month
[JBoss JIRA] (ISPN-4945) Remote listener can fail with NPE
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4945?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4945:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1162199|https://bugzilla.redhat.com/show_bug.cgi?id=1162199] from NEW to ASSIGNED
> Remote listener can fail with NPE
> ---------------------------------
>
> Key: ISPN-4945
> URL: https://issues.jboss.org/browse/ISPN-4945
> Project: Infinispan
> Issue Type: Bug
> Components: Server
> Affects Versions: 7.0.0.Final
> Reporter: Vojtech Juranek
> Assignee: Galder Zamarreño
> Priority: Critical
> Fix For: 7.0.1.Final
>
>
> When event sender generates the event, it access metadata which can be {{null}} and thus it fails with NPE:
> {noformat}
> [0m[31m09:46:22,182 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (HotRodServerWorker-7-17) ISPN000136: Execution error: org.infinispan.commons.CacheListenerException: ISPN000280: Caught exception [java.lang.NullPointerException] while invoking method [public void org.infinispan.server.hotrod.ClientListenerRegistry$BaseClientEventSender.onCacheEvent(org.infinispan.notifications.cachelistener.event.CacheEntryEvent)] on listener instance: org.infinispan.server.hotrod.ClientListenerRegistry$StatelessClientEventSender@2a39f240
> at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl$1.run(AbstractListenerImpl.java:286) [infinispan-core.jar:7.0.0.CR1]
> at org.infinispan.util.concurrent.WithinThreadExecutor.execute(WithinThreadExecutor.java:22) [infinispan-core.jar:7.0.0.CR1]
> at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl.invoke(AbstractListenerImpl.java:304) [infinispan-core.jar:7.0.0.CR1]
> at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.doRealInvocation(CacheNotifierImpl.java:986) [infinispan-core.jar:7.0.0.CR1]
> at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invokeNoChecks(CacheNotifierImpl.java:981) [infinispan-core.jar:7.0.0.CR1]
> at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invoke(CacheNotifierImpl.java:962) [infinispan-core.jar:7.0.0.CR1]
> at org.infinispan.notifications.cachelistener.CacheNotifierImpl.notifyCacheEntryRemoved(CacheNotifierImpl.java:278) [infinispan-core.jar:7.0.0.CR1]
> at org.infinispan.interceptors.locking.ClusteringDependentLogic$AbstractClusteringDependentLogic.notifyCommitEntry(ClusteringDependentLogic.java:111) [infinispan-core.jar:7.0.0.CR1]
> at org.infinispan.interceptors.locking.ClusteringDependentLogic$DistributionLogic.commitEntry(ClusteringDependentLogic.java:475) [infinispan-core.jar:7.0.0.CR1]
> at org.infinispan.interceptors.EntryWrappingInterceptor.commitContextEntry(EntryWrappingInterceptor.java:359) [infinispan-core.jar:7.0.0.CR1]
> at org.infinispan.interceptors.EntryWrappingInterceptor.commitEntryIfNeeded(EntryWrappingInterceptor.java:577) [infinispan-core.jar:7.0.0.CR1]
> at org.infinispan.interceptors.EntryWrappingInterceptor.commitContextEntries(EntryWrappingInterceptor.java:336) [infinispan-core.jar:7.0.0.CR1]
> at org.infinispan.interceptors.EntryWrappingInterceptor.invokeNextAndApplyChanges(EntryWrappingInterceptor.java:410) [infinispan-core.jar:7.0.0.CR1]
> at org.infinispan.interceptors.EntryWrappingInterceptor.setSkipRemoteGetsAndInvokeNextForDataCommand(EntryWrappingInterceptor.java:464) [infinispan-core.jar:7.0.0.CR1]
> at org.infinispan.interceptors.EntryWrappingInterceptor.visitRemoveCommand(EntryWrappingInterceptor.java:234) [infinispan-core.jar:7.0.0.CR1]
> at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58) [infinispan-core.jar:7.0.0.CR1]
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core.jar:7.0.0.CR1]
> at org.infinispan.interceptors.locking.NonTransactionalLockingInterceptor.visitRemoveCommand(NonTransactionalLockingInterceptor.java:83) [infinispan-core.jar:7.0.0.CR1]
> at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58) [infinispan-core.jar:7.0.0.CR1]
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core.jar:7.0.0.CR1]
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112) [infinispan-core.jar:7.0.0.CR1]
> at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:38) [infinispan-core.jar:7.0.0.CR1]
> at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58) [infinispan-core.jar:7.0.0.CR1]
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core.jar:7.0.0.CR1]
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112) [infinispan-core.jar:7.0.0.CR1]
> at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:38) [infinispan-core.jar:7.0.0.CR1]
> at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58) [infinispan-core.jar:7.0.0.CR1]
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core.jar:7.0.0.CR1]
> at org.infinispan.statetransfer.StateTransferInterceptor.handleNonTxWriteCommand(StateTransferInterceptor.java:172) [infinispan-core.jar:7.0.0.CR1]
> at org.infinispan.statetransfer.StateTransferInterceptor.visitRemoveCommand(StateTransferInterceptor.java:110) [infinispan-core.jar:7.0.0.CR1]
> at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58) [infinispan-core.jar:7.0.0.CR1]
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core.jar:7.0.0.CR1]
> at org.infinispan.interceptors.CacheMgmtInterceptor.visitRemoveCommand(CacheMgmtInterceptor.java:166) [infinispan-core.jar:7.0.0.CR1]
> at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58) [infinispan-core.jar:7.0.0.CR1]
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core.jar:7.0.0.CR1]
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:102) [infinispan-core.jar:7.0.0.CR1]
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:71) [infinispan-core.jar:7.0.0.CR1]
> at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:38) [infinispan-core.jar:7.0.0.CR1]
> at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58) [infinispan-core.jar:7.0.0.CR1]
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:333) [infinispan-core.jar:7.0.0.CR1]
> at org.infinispan.cache.impl.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1492) [infinispan-core.jar:7.0.0.CR1]
> at org.infinispan.cache.impl.CacheImpl.removeInternal(CacheImpl.java:504) [infinispan-core.jar:7.0.0.CR1]
> at org.infinispan.cache.impl.CacheImpl.remove(CacheImpl.java:497) [infinispan-core.jar:7.0.0.CR1]
> at org.infinispan.cache.impl.CacheImpl.remove(CacheImpl.java:492) [infinispan-core.jar:7.0.0.CR1]
> at org.infinispan.cache.impl.AbstractDelegatingCache.remove(AbstractDelegatingCache.java:287) [infinispan-core.jar:7.0.0.CR1]
> at org.infinispan.server.core.AbstractProtocolDecoder.remove(AbstractProtocolDecoder.scala:322) [infinispan.jar:7.0.0.CR1]
> at org.infinispan.server.core.AbstractProtocolDecoder.handleModification(AbstractProtocolDecoder.scala:179) [infinispan.jar:7.0.0.CR1]
> at org.infinispan.server.core.AbstractProtocolDecoder.org$infinispan$server$core$AbstractProtocolDecoder$$decodeKey(AbstractProtocolDecoder.scala:166) [infinispan.jar:7.0.0.CR1]
> at org.infinispan.server.core.AbstractProtocolDecoder.decodeDispatch(AbstractProtocolDecoder.scala:71) [infinispan.jar:7.0.0.CR1]
> at org.infinispan.server.core.AbstractProtocolDecoder.decode(AbstractProtocolDecoder.scala:61) [infinispan.jar:7.0.0.CR1]
> at io.netty.handler.codec.ReplayingDecoder.callDecode(ReplayingDecoder.java:362) [netty-all-4.0.20.Final.jar:4.0.20.Final]
> at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:149) [netty-all-4.0.20.Final.jar:4.0.20.Final]
> at org.infinispan.server.core.AbstractProtocolDecoder.channelRead(AbstractProtocolDecoder.scala:471) [infinispan.jar:7.0.0.CR1]
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:332) [netty-all-4.0.20.Final.jar:4.0.20.Final]
> at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:318) [netty-all-4.0.20.Final.jar:4.0.20.Final]
> at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:787) [netty-all-4.0.20.Final.jar:4.0.20.Final]
> at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:125) [netty-all-4.0.20.Final.jar:4.0.20.Final]
> at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:507) [netty-all-4.0.20.Final.jar:4.0.20.Final]
> at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:464) [netty-all-4.0.20.Final.jar:4.0.20.Final]
> at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:378) [netty-all-4.0.20.Final.jar:4.0.20.Final]
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:350) [netty-all-4.0.20.Final.jar:4.0.20.Final]
> at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116) [netty-all-4.0.20.Final.jar:4.0.20.Final]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_67]
> Caused by: java.lang.NullPointerException
> at org.infinispan.server.hotrod.ClientListenerRegistry$BaseClientEventSender.onCacheEvent(ClientListenerRegistry.scala:161) [infinispan.jar:7.0.0.CR1]
> at sun.reflect.GeneratedMethodAccessor37.invoke(Unknown Source) [:1.7.0_67]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_67]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_67]
> at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl$1.run(AbstractListenerImpl.java:281) [infinispan-core.jar:7.0.0.CR1]
> ... 62 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
10 years, 1 month
[JBoss JIRA] (ISPN-4546) Possible stale lock when the primary owner leaves during rebalance
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-4546?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-4546:
----------------------------------
Assignee: Dan Berindei
> Possible stale lock when the primary owner leaves during rebalance
> ------------------------------------------------------------------
>
> Key: ISPN-4546
> URL: https://issues.jboss.org/browse/ISPN-4546
> Project: Infinispan
> Issue Type: Bug
> Components: Core, State Transfer
> Affects Versions: 7.0.0.Alpha5
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Critical
> Fix For: 7.1.0.Alpha1
>
>
> Topology T: coordinator = A, owners(k) = [C, D], pending_owners(k) = null
> B sends prepareCommand(tx1, put(k, v)) to C, D
> D adds backup locks and replies
> C acquires lock, ready to send reply to B
> A starts installing topology T+1: owners(k) = [C, D], pending_owners(k) = [C, E]
> A, C and E install topology T+1, B and D do not
> E requests and receives tx data from C, including tx1
> C leaves
> B sees a SuspectException, sends rollbackCommand(tx1) to C, D
> D removes tx1
> C has left, but is ignored
> B reports to the user that the tx has been rolled back
> B and D install topology T+1 (optional)
> A starts installing topology T+2: owners(k) = [D], pending_owners(k) = [E]
> A, B, D, E all install topology T+2
> E requests and receives state from D, but it does not remove tx1
> A starts installing topology T+3: owners(k) = [E], pending_owners(k) = null
> E now has a stale backup lock on k
> It seems very hard to reproduce in production: C would have to leave soon enough so that B and D haven't received the T+1 topology yet, but late enough for it to send its transaction data to E.
> A possible solution would be to catch any SuspectException during prepare/commit/rollback (without ignoring leavers), wait for a new topology, and replicate the command again on the new owners. Obviously, this wouldn't work with asynchronous prepare/commit/rollback.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
10 years, 1 month
[JBoss JIRA] (ISPN-4546) Possible stale lock when the primary owner leaves during rebalance
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4546?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4546:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1163727|https://bugzilla.redhat.com/show_bug.cgi?id=1163727] from NEW to ASSIGNED
> Possible stale lock when the primary owner leaves during rebalance
> ------------------------------------------------------------------
>
> Key: ISPN-4546
> URL: https://issues.jboss.org/browse/ISPN-4546
> Project: Infinispan
> Issue Type: Bug
> Components: Core, State Transfer
> Affects Versions: 7.0.0.Alpha5
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Critical
> Fix For: 7.1.0.Alpha1
>
>
> Topology T: coordinator = A, owners(k) = [C, D], pending_owners(k) = null
> B sends prepareCommand(tx1, put(k, v)) to C, D
> D adds backup locks and replies
> C acquires lock, ready to send reply to B
> A starts installing topology T+1: owners(k) = [C, D], pending_owners(k) = [C, E]
> A, C and E install topology T+1, B and D do not
> E requests and receives tx data from C, including tx1
> C leaves
> B sees a SuspectException, sends rollbackCommand(tx1) to C, D
> D removes tx1
> C has left, but is ignored
> B reports to the user that the tx has been rolled back
> B and D install topology T+1 (optional)
> A starts installing topology T+2: owners(k) = [D], pending_owners(k) = [E]
> A, B, D, E all install topology T+2
> E requests and receives state from D, but it does not remove tx1
> A starts installing topology T+3: owners(k) = [E], pending_owners(k) = null
> E now has a stale backup lock on k
> It seems very hard to reproduce in production: C would have to leave soon enough so that B and D haven't received the T+1 topology yet, but late enough for it to send its transaction data to E.
> A possible solution would be to catch any SuspectException during prepare/commit/rollback (without ignoring leavers), wait for a new topology, and replicate the command again on the new owners. Obviously, this wouldn't work with asynchronous prepare/commit/rollback.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
10 years, 1 month
[JBoss JIRA] (ISPN-4286) Two concurrent putIfAbsent operations can both return null during rebalance
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4286?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4286:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1163725|https://bugzilla.redhat.com/show_bug.cgi?id=1163725] from NEW to ASSIGNED
> Two concurrent putIfAbsent operations can both return null during rebalance
> ---------------------------------------------------------------------------
>
> Key: ISPN-4286
> URL: https://issues.jboss.org/browse/ISPN-4286
> Project: Infinispan
> Issue Type: Bug
> Components: Core, State Transfer
> Affects Versions: 6.0.2.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Critical
> Fix For: 7.1.0.Alpha1
>
>
> If the cache topology changes while executing a putIfAbsent operation, the old primary owner will throw an OutdatedTopologyException, and the originator will retry on the new owner.
> When retrying the PutKeyValueCommand on the new primary owner, we compare the current value with the command's new value. If they are equal, we assume that the initial command wrote the old value, and we return {{null}}.
> However, the value might have been written by another putIfAbsent operation. So we could have two {{putIfAbsent(k, v)}} operations, both returning {{null}}.
> {code}
> A is the originator, B is the primary owner, k = null
> A -> B: putIfAbsent(k, v1)
> B dies before writing v, C is now primary owner
> D -> C: putIfAbsent(k, v1) // another put operation from D, with the same value
> C -> D: null // correct
> A -> C: retry_putIfAbsent(k, v1)
> C -> A: null // C assumes A is overwriting its own value, so it's also returning null
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
10 years, 1 month
[JBoss JIRA] (ISPN-4909) Test clearTempDir throws NullPointerException on all Enviroments
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4909?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4909:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1158827|https://bugzilla.redhat.com/show_bug.cgi?id=1158827] from NEW to ASSIGNED
> Test clearTempDir throws NullPointerException on all Enviroments
> ----------------------------------------------------------------
>
> Key: ISPN-4909
> URL: https://issues.jboss.org/browse/ISPN-4909
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Core
> Reporter: Roman Macor
>
> Description of problem:
> Infinispan testsuite test org.infinispan.persistence.leveldb.config.ConfigurationTest.clearTempDir throws NullPointerException on all Enviroments.
> Full trace log:
> java.lang.NullPointerException
> at java.io.File.<init>(File.java:277)
> at org.infinispan.test.TestingUtil.recursiveFileRemove(TestingUtil.java:566)
> at org.infinispan.persistence.leveldb.config.ConfigurationTest.clearTempDir(ConfigurationTest.java:44)
> 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.invokeConfigurations(Invoker.java:138)
> at org.testng.TestRunner.afterRun(TestRunner.java:1021)
> at org.testng.TestRunner.run(TestRunner.java:621)
> 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:745)
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
10 years, 1 month