[JBoss JIRA] (ISPN-374) Add event handling to Hot Rod
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-374?page=com.atlassian.jira.plugin.s... ]
Mircea Markus updated ISPN-374:
-------------------------------
Fix Version/s: 7.0.0.Alpha3
> Add event handling to Hot Rod
> -----------------------------
>
> Key: ISPN-374
> URL: https://issues.jboss.org/browse/ISPN-374
> Project: Infinispan
> Issue Type: Feature Request
> Components: Remote Protocols
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Labels: roadmap
> Fix For: 7.0.0.Alpha3
>
>
> Enable Hot Rod servers to send events asynchronously to registered clients over persistent connections. This would allow use cases such as clients maintaining L1 caches and these events could be used for servers to invalidate keys on the client side. See dev list thread for more info.
--
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-374) Add event handling to Hot Rod
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-374?page=com.atlassian.jira.plugin.s... ]
Mircea Markus updated ISPN-374:
-------------------------------
Labels: roadmap (was: hackathon)
> Add event handling to Hot Rod
> -----------------------------
>
> Key: ISPN-374
> URL: https://issues.jboss.org/browse/ISPN-374
> Project: Infinispan
> Issue Type: Feature Request
> Components: Remote Protocols
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Labels: roadmap
>
> Enable Hot Rod servers to send events asynchronously to registered clients over persistent connections. This would allow use cases such as clients maintaining L1 caches and these events could be used for servers to invalidate keys on the client side. See dev list thread for more info.
--
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 Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-4131?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-4131:
-------------------------------
Workaround Description: There is a workaround, to increase completedTxTimeout until it's bigger than the state transfer timeout.
> 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 Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-4131?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-4131:
-------------------------------
Workaround: Workaround Exists
> 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