[JBoss JIRA] (ISPN-4131) Lock acquired forever with delayed PrepareCommand
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-4131?page=com.atlassian.jira.plugin.... ]
Radim Vansa updated ISPN-4131:
------------------------------
Affects Version/s: 6.0.2.Final
> 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
>
> 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 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-4131) Lock acquired forever with delayed PrepareCommand
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-4131?page=com.atlassian.jira.plugin.... ]
Radim Vansa updated ISPN-4131:
------------------------------
Description:
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.
was:
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 things it was already rolled back.
Result: key K will be locked forever, all attempts to update/remove it will fail.
> 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: 7.0.0.Alpha1
> Reporter: Radim Vansa
> Assignee: Dan Berindei
> Priority: Critical
>
> 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 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-4131) Lock acquired forever with delayed PrepareCommand
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-4131?page=com.atlassian.jira.plugin.... ]
Radim Vansa updated ISPN-4131:
------------------------------
Priority: Critical (was: Major)
> 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: 7.0.0.Alpha1
> Reporter: Radim Vansa
> Assignee: Dan Berindei
> Priority: Critical
>
> 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 things it was already rolled back.
> Result: key K will be locked forever
--
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-4131) Lock acquired forever with delayed PrepareCommand
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-4131?page=com.atlassian.jira.plugin.... ]
Radim Vansa updated ISPN-4131:
------------------------------
Description:
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 things it was already rolled back.
Result: key K will be locked forever, all attempts to update/remove it will fail.
was:
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 things it was already rolled back.
Result: key K will be locked forever
> 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: 7.0.0.Alpha1
> Reporter: Radim Vansa
> Assignee: Dan Berindei
> Priority: Critical
>
> 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 things it was already rolled back.
> Result: key K will be locked forever, all attempts to update/remove it will fail.
--
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-4131) Lock acquired forever with delayed PrepareCommand
by Radim Vansa (JIRA)
Radim Vansa created ISPN-4131:
---------------------------------
Summary: 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: 7.0.0.Alpha1
Reporter: Radim Vansa
Assignee: Dan Berindei
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 things it was already rolled back.
Result: key K will be locked forever
--
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-4130) Upgrade to Apache Avro 1.7.6
by Sanne Grinovero (JIRA)
Sanne Grinovero created ISPN-4130:
-------------------------------------
Summary: Upgrade to Apache Avro 1.7.6
Key: ISPN-4130
URL: https://issues.jboss.org/browse/ISPN-4130
Project: Infinispan
Issue Type: Component Upgrade
Components: Remote Protocols
Reporter: Sanne Grinovero
Assignee: Sanne Grinovero
Priority: Trivial
Fix For: 7.0.0.Alpha2
I'm aligning the dependency set across various projects to latest Avro: seems a trivial upgrade, with a long list of bugs fixed.
--
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