[JBoss JIRA] (ISPN-3389) Forwarded transactions can remain stale after state transfer
by Erik Salter (JIRA)
[ https://issues.jboss.org/browse/ISPN-3389?page=com.atlassian.jira.plugin.... ]
Erik Salter edited comment on ISPN-3389 at 8/22/13 4:33 PM:
------------------------------------------------------------
The originating node is:
https://dl.dropboxusercontent.com/u/50401510/ISPN-3389/originating_node/s...
An example of the stale transaction is on the new owner of this key:
https://dl.dropboxusercontent.com/u/50401510/ISPN-3389/forwarded_node/ser...
(NOTE: This system lost connectivity to their NTP server, so there's tremendous drift on the system times).
was (Author: an1310):
The originating node is:
https://dl.dropboxusercontent.com/u/50401510/ISPN-3389/originating_node/s...
> Forwarded transactions can remain stale after state transfer
> ------------------------------------------------------------
>
> Key: ISPN-3389
> URL: https://issues.jboss.org/browse/ISPN-3389
> Project: Infinispan
> Issue Type: Bug
> Components: State transfer
> Affects Versions: 5.2.7.Final
> Reporter: Erik Salter
> Assignee: Dan Berindei
> Priority: Critical
> Labels: 5.2.x
> Fix For: 6.0.0.CR1, 6.0.0.Final
>
>
> There is a scenario where a tx started on one node, moved during state transfer, and committed on the originating node won't be removed from the new owner's tx table.
> The chain of events is as follows:
> 1. New topology comes in as part of a view change.
> 2. Local transaction started with the new topology ID. This transaction was started due to a LockControlCommand and has no modifications. Also important, it only has local locks.
> 3. Tx forwarded to new owner before the local lock is acquired and registered with the transaction.
> 4. Since the tx has only local locks and no modifications, it is only removed locally. No TxCompletion or Rollback are broadcast to the new owners.
> This key becomes unusable not due to stale locks, but because the waitForTransaction() code will see that the old tx can "potentially" lock the key.
> This easily happens with pessimistic caches, though I have seen it happen with optimistic caches (there is a delta between the transaction being created and the lock registration).
--
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, 7 months
[JBoss JIRA] (ISPN-3389) Forwarded transactions can remain stale after state transfer
by Erik Salter (JIRA)
[ https://issues.jboss.org/browse/ISPN-3389?page=com.atlassian.jira.plugin.... ]
Erik Salter commented on ISPN-3389:
-----------------------------------
The originating node is:
https://dl.dropboxusercontent.com/u/50401510/ISPN-3389/originating_node/s...
> Forwarded transactions can remain stale after state transfer
> ------------------------------------------------------------
>
> Key: ISPN-3389
> URL: https://issues.jboss.org/browse/ISPN-3389
> Project: Infinispan
> Issue Type: Bug
> Components: State transfer
> Affects Versions: 5.2.7.Final
> Reporter: Erik Salter
> Assignee: Dan Berindei
> Priority: Critical
> Labels: 5.2.x
> Fix For: 6.0.0.CR1, 6.0.0.Final
>
>
> There is a scenario where a tx started on one node, moved during state transfer, and committed on the originating node won't be removed from the new owner's tx table.
> The chain of events is as follows:
> 1. New topology comes in as part of a view change.
> 2. Local transaction started with the new topology ID. This transaction was started due to a LockControlCommand and has no modifications. Also important, it only has local locks.
> 3. Tx forwarded to new owner before the local lock is acquired and registered with the transaction.
> 4. Since the tx has only local locks and no modifications, it is only removed locally. No TxCompletion or Rollback are broadcast to the new owners.
> This key becomes unusable not due to stale locks, but because the waitForTransaction() code will see that the old tx can "potentially" lock the key.
> This easily happens with pessimistic caches, though I have seen it happen with optimistic caches (there is a delta between the transaction being created and the lock registration).
--
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, 7 months
[JBoss JIRA] (ISPN-3173) Define a new query operation over hotrod
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-3173?page=com.atlassian.jira.plugin.... ]
Adrian Nistor commented on ISPN-3173:
-------------------------------------
[~galderz] It looks fine and I've made a PR from your branch to speedup integration while you're away. I've made a single change: modified signature of QueryFacade.query() to have the cache as parameter and also declare a thrown exception.
> Define a new query operation over hotrod
> ----------------------------------------
>
> Key: ISPN-3173
> URL: https://issues.jboss.org/browse/ISPN-3173
> Project: Infinispan
> Issue Type: Sub-task
> Reporter: Mircea Markus
> Assignee: Galder Zamarreño
> Priority: Blocker
> Fix For: 6.0.0.Alpha3, 6.0.0.Final
>
>
> Add a new query predicated to the [Hot Rod Protocol | https://docs.jboss.org/author/display/ISPN/Hot+Rod+Protocol+-+Version+1.2] and implement server side support for it.
> For now this operation should send an byte[] (the query encoded) over the network and receive an byte[] as response. The query and the result might get further specified in the future.
> This will be used by ISPN-3175 to implement the initial remote querying functionality the java hotrod client.
--
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, 7 months