[JBoss JIRA] (ISPN-4190) Use Message.Flag.DONT_LOOPBACK instead of RequestOptions.setExclusionList
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-4190?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-4190:
------------------------------------
Doesn't work yet, because `MessageDispatcher.cast()` doesn't remove the local node from the `real_dests` collection when using `DONT_LOOPBACK`.
> Use Message.Flag.DONT_LOOPBACK instead of RequestOptions.setExclusionList
> -------------------------------------------------------------------------
>
> Key: ISPN-4190
> URL: https://issues.jboss.org/browse/ISPN-4190
> Project: Infinispan
> Issue Type: Task
> Components: Core
> Affects Versions: 7.0.0.Alpha2
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 7.0.0.Alpha3
>
>
> We are currently using {{RequestOptions.setExclusionList(channel.getAddress())}} in CommandAwareRpcDispatcher, to prevent the sender of an RPC to receive that message. We can't use {{Channel.setDiscardOwnMessages(true)}}, because TO requires messages to be delivered to self.
> JGroups 3.5.0.Beta2 has added a {{DONT_LOOPBACK}} flag, which should be a lot more efficient than using the exclusion list. We should start using it.
--
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
12 years
[JBoss JIRA] (ISPN-3873) Race condition in AbstractInvocationContextFactory (results in NullPointerException in EquivalentHashMap when receiving an invalidate command during startup)
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3873?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3873:
-----------------------------------------------
Vojtech Juranek <vjuranek(a)redhat.com> changed the Status of [bug 1083508|https://bugzilla.redhat.com/show_bug.cgi?id=1083508] from ON_QA to VERIFIED
> Race condition in AbstractInvocationContextFactory (results in NullPointerException in EquivalentHashMap when receiving an invalidate command during startup)
> -------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-3873
> URL: https://issues.jboss.org/browse/ISPN-3873
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 6.0.1.Final
> Environment: Ubuntu Linux 12.04_LTS, Oracle Java SE 1.7.0_45
> Reporter: Karl von Randow
> Assignee: Dan Berindei
> Labels: 630
> Fix For: 7.0.0.Alpha1, 7.0.0.Final
>
> Attachments: infinispan.trace.gz
>
>
> Sometimes when I start one server in a cluster I see the NullPointerException reproduced below. This only occurs if there is another server running. I run multiple caches with clustering using invalidation. JGroups using JDBC_PING and TCP. The caches are non-transactional.
> The NPE is because the keyEq (Equivalence instance for keys) is null. I believe this is because the command is processed before the start() method has been called on the AbstractInvocationContextFactory, as the start() method sets the keyEq ivar.
> At this point I'm not sure how to fix it!
> java.lang.NullPointerException
> at org.infinispan.commons.equivalence.EquivalentHashMap.put(EquivalentHashMap.java:176)
> at org.infinispan.commons.equivalence.EquivalentHashSet.add(EquivalentHashSet.java:109)
> at org.infinispan.context.impl.NonTxInvocationContext.addLockedKey(NonTxInvocationContext.java:84)
> at org.infinispan.util.concurrent.locks.LockManagerImpl.lock(LockManagerImpl.java:190)
> at org.infinispan.util.concurrent.locks.LockManagerImpl.acquireLockNoCheck(LockManagerImpl.java:181)
> at org.infinispan.interceptors.locking.AbstractLockingInterceptor.lockKey(AbstractLockingInterceptor.java:149)
> at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitInvalidateCommand(AbstractLockingInterceptor.java:85)
> at org.infinispan.commands.write.InvalidateCommand.acceptVisitor(InvalidateCommand.java:118)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112)
> at org.infinispan.commands.AbstractVisitor.visitInvalidateCommand(AbstractVisitor.java:111)
> at org.infinispan.commands.write.InvalidateCommand.acceptVisitor(InvalidateCommand.java:118)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112)
> at org.infinispan.commands.AbstractVisitor.visitInvalidateCommand(AbstractVisitor.java:111)
> at org.infinispan.commands.write.InvalidateCommand.acceptVisitor(InvalidateCommand.java:118)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:110)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:73)
> at org.infinispan.commands.AbstractVisitor.visitInvalidateCommand(AbstractVisitor.java:111)
> at org.infinispan.commands.write.InvalidateCommand.acceptVisitor(InvalidateCommand.java:118)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:333)
> at org.infinispan.commands.remote.BaseRpcInvokingCommand.processVisitableCommand(BaseRpcInvokingCommand.java:39)
> at org.infinispan.commands.remote.SingleRpcCommand.perform(SingleRpcCommand.java:48)
> at org.infinispan.remoting.InboundInvocationHandlerImpl.handleInternal(InboundInvocationHandlerImpl.java:95)
> at org.infinispan.remoting.InboundInvocationHandlerImpl.handleWithWaitForBlocks(InboundInvocationHandlerImpl.java:186)
> at org.infinispan.remoting.InboundInvocationHandlerImpl.handle(InboundInvocationHandlerImpl.java:84)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommandFromLocalCluster(CommandAwareRpcDispatcher.java:259)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:211)
> at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:460)
> at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:377)
> at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:247)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:665)
> at org.jgroups.JChannel.up(JChannel.java:730)
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1019)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:182)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:434)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:434)
> at org.jgroups.stack.Protocol.up(Protocol.java:409)
> at org.jgroups.stack.Protocol.up(Protocol.java:409)
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:294)
> at org.jgroups.protocols.RSVP.up(RSVP.java:221)
> at org.jgroups.protocols.UNICAST2.removeAndPassUp(UNICAST2.java:919)
> at org.jgroups.protocols.UNICAST2.handleDataReceived(UNICAST2.java:800)
> at org.jgroups.protocols.UNICAST2.up(UNICAST2.java:415)
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:600)
> at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:147)
> at org.jgroups.protocols.FD.up(FD.java:255)
> at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:301)
> at org.jgroups.protocols.MERGE2.up(MERGE2.java:209)
> at org.jgroups.protocols.Discovery.up(Discovery.java:379)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1399)
> at org.jgroups.protocols.TP$MyHandler.run(TP.java:1585)
> 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)
--
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
12 years
[JBoss JIRA] (ISPN-4091) Transactions and data should prefer to be sourced from a primary owner
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-4091?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-4091:
-------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/2484
> Transactions and data should prefer to be sourced from a primary owner
> ----------------------------------------------------------------------
>
> Key: ISPN-4091
> URL: https://issues.jboss.org/browse/ISPN-4091
> Project: Infinispan
> Issue Type: Bug
> Components: State Transfer
> Affects Versions: 5.2.7.Final
> Reporter: Erik Salter
> Assignee: Dan Berindei
>
> The current state transfer mechanism will ask the backup segments for transaction and state information. However, this breaks if there is a pessimistic transaction executing on the primary data owner, Consider the following use case:
> A new owner joins and sources the ongoing transactions and data for key k from the backup. Meanwhile, a local transaction has started on the primary owner for k, but has not prepared on any remote nodes. So the new node does not know about the ongoing transaction. While that's going on, a new tx starts on the new owner. Since these are pessimistic, the new transaction will acquires the lock for the same key.
> So we can have data inconsistency.
> The state transfer mechanism should prefer to source the transaction and state information from the primary owner. This should cover all cases: if the originator is not the primary owner, then any (backup) locks must be replicated to all the owners, either directly during the tx or during a previous state transfer.
--
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
12 years
[JBoss JIRA] (ISPN-4108) Pessimistic tx for a union CH will not be forwarded to all owners.
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-4108?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-4108:
-------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/2484
> Pessimistic tx for a union CH will not be forwarded to all owners.
> ------------------------------------------------------------------
>
> Key: ISPN-4108
> URL: https://issues.jboss.org/browse/ISPN-4108
> Project: Infinispan
> Issue Type: Bug
> Components: State Transfer
> Affects Versions: 5.2.7.Final
> Reporter: Erik Salter
> Assignee: Dan Berindei
>
> There is a case where transactions originating from a LockControlCommand will not be forwarded to the new owner during state transfer.
> If the transactions begin on the old primary owner after the tx list was sent to the new owner, the lock information may not be replicated to the joiner because the originator is still the primary owner in the union CH that we use during state transfer. When state transfer ends and the joiner becomes the new primary owner, it will allow other txs to lock the same key. This leads to data loss/inconsistency.
> We should change PessimisticLockingInterceptor to replicate the lock command to the other owners even if the originator is the primary owner when there is a state transfer in progress.
--
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
12 years
[JBoss JIRA] (ISPN-4190) Use Message.Flag.DONT_LOOPBACK instead of RequestOptions.setExclusionList
by Dan Berindei (JIRA)
Dan Berindei created ISPN-4190:
----------------------------------
Summary: Use Message.Flag.DONT_LOOPBACK instead of RequestOptions.setExclusionList
Key: ISPN-4190
URL: https://issues.jboss.org/browse/ISPN-4190
Project: Infinispan
Issue Type: Task
Components: Core
Affects Versions: 7.0.0.Alpha2
Reporter: Dan Berindei
Assignee: Dan Berindei
Fix For: 7.0.0.Alpha3
We are currently using {{RequestOptions.setExclusionList(channel.getAddress())}} in CommandAwareRpcDispatcher, to prevent the sender of an RPC to receive that message. We can't use {{Channel.setDiscardOwnMessages(true)}}, because TO requires messages to be delivered to self.
JGroups 3.5.0.Beta2 has added a {{DONT_LOOPBACK}} flag, which should be a lot more efficient than using the exclusion list. We should start using it.
--
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
12 years
[JBoss JIRA] (ISPN-4085) Random failures in StateProviderTest due to race condition
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4085?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4085:
-----------------------------------------------
Vojtech Juranek <vjuranek(a)redhat.com> changed the Status of [bug 1083112|https://bugzilla.redhat.com/show_bug.cgi?id=1083112] from ON_QA to VERIFIED
> Random failures in StateProviderTest due to race condition
> ----------------------------------------------------------
>
> Key: ISPN-4085
> URL: https://issues.jboss.org/browse/ISPN-4085
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Core
> Affects Versions: 7.0.0.Alpha1
> Environment: jgroups.bind_addr = 127.0.0.1
> java.runtime.version = 1.7.0_51-b13
> java.runtime.name =Java(TM) SE Runtime Environment
> java.vm.version = 24.51-b03
> java.vm.vendor = Oracle Corporation
> os.name = Mac OS X
> os.version = 10.9.2
> sun.arch.data.model = 64
> sun.cpu.endian = little
> protocol.stack = null
> infinispan.test.jgroups.protocol = tcp
> infinispan.unsafe.allow_jdk8_chm = true
> java.net.preferIPv4Stack = true
> java.net.preferIPv6Stack = null
> log4.configuration = null
> MAVEN_OPTS = null
> Reporter: Gustavo Fernandes
> Assignee: Adrian Nistor
> Labels: 630
> Fix For: 7.0.0.Alpha2, 7.0.0.Final
>
>
> In my environment the StateProviderTest .test2() fails sometimes (about 10% of the time) with the following error(s):
> {code}
> Tests run: 4233, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 428.06 sec <<< FAILURE!
> test2(org.infinispan.statetransfer.StateProviderTest) Time elapsed: 0.042 sec <<< FAILURE!
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:92)
> at org.junit.Assert.assertTrue(Assert.java:43)
> at org.junit.Assert.assertTrue(Assert.java:54)
> at org.infinispan.statetransfer.StateProviderTest.test2(StateProviderTest.java:316)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> {code}
> The reason why is that test2() feeds the StateProvider a ThreadPoolExecutorService to execute a OutboundTransfer task asynchronously and right after forcing a state transfer
> asserts that there is a StateTransfer in progress. Sometimes the executor service manages to execute the task and as a result it clear the ‘transfersByDestination’ map, and thus the test cannot assert that the state transfer is happening
> OTOH, the method test1() never fails because it users a mock executor service which never executes the task, so the state transfer map will always contain the outbound task after initiating the state transfer and thus always visible from outside
> The quick fix is to also use a mock executor test for the test2()
--
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
12 years