[JBoss JIRA] (ISPN-4131) Lock acquired forever with delayed PrepareCommand
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-4131?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-4131:
-----------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 7.0.0.Beta1
7.0.0.Final
Resolution: Done
> Lock acquired forever with delayed PrepareCommand
> -------------------------------------------------
>
> Key: ISPN-4131
> URL: https://issues.jboss.org/browse/ISPN-4131
> Project: Infinispan
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 6.0.2.Final, 7.0.0.Alpha1
> Reporter: Radim Vansa
> Assignee: Dan Berindei
> Priority: Critical
> Labels: 630betablocker
> Fix For: 7.0.0.Beta1, 7.0.0.Final
>
>
> Distributed transactional cache:
> 1. A sends Prepare to B
> 2. B receives Prepare, but due to ongoing ST it is blocked
> 3. B replication timeout elapses
> 4. B sends Rollback, this does not find the TX as Prepare was not executed yet. The transaction is put into completedTransactions.
> 5. Completed transactions timeout elapses. This is by default 15 seconds, way shorter than ST timeout (due to which the Prepare was blocked)
> 6. Prepare is executed on B, acquiring lock on K
> Nobody will rollback the TX as originator thinks it was already rolled back.
> Result: key K will be locked forever, all attempts to update/remove it will fail.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
11 years, 11 months
[JBoss JIRA] (ISPN-4190) Use Message.Flag.DONT_LOOPBACK instead of RequestOptions.setExclusionList
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/ISPN-4190?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on ISPN-4190:
--------------------------------
Make sure you test TO with both SEQUENCER and TOA, too. I didn't look at these 2 protocols.
> 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.Beta1
>
>
> 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 was sent by Atlassian JIRA
(v6.2.3#6260)
11 years, 11 months
[JBoss JIRA] (ISPN-4190) Use Message.Flag.DONT_LOOPBACK instead of RequestOptions.setExclusionList
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-4190?page=com.atlassian.jira.plugin.... ]
William Burns commented on ISPN-4190:
-------------------------------------
This should be working with the latest JGroups
Also to keep in mind:
bela_> DONT_LOOPBACK is only implemented in UNICAST3 and NAKACK2
> 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.Beta1
>
>
> 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 was sent by Atlassian JIRA
(v6.2.3#6260)
11 years, 11 months