[JBoss JIRA] (ISPN-3315) Retry remote get after topology change if all the targets are no longer owners
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-3315?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-3315:
------------------------------
Fix Version/s: 6.0.0.CR2
> Retry remote get after topology change if all the targets are no longer owners
> ------------------------------------------------------------------------------
>
> Key: ISPN-3315
> URL: https://issues.jboss.org/browse/ISPN-3315
> Project: Infinispan
> Issue Type: Bug
> Components: State transfer
> Affects Versions: 5.3.0.Final
> Reporter: Dan Berindei
> Assignee: Pedro Ruivo
> Priority: Critical
> Labels: 620
> Fix For: 6.0.0.CR2, 6.0.0.Final
>
>
> It's possible for a remote get to reach its intended targets only after they are no longer owners, and they don't have the key anymore. If that happens, instead of returning a {{null}} value, the originator should retry on the new owners (possibly in a loop).
> Note that this is different from all the owners leaving the cluster at the same time: in that case retrying on the new owners wouldn't make a difference, because data would be lost anyway.
--
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, 5 months
[JBoss JIRA] (ISPN-3693) ActivationInterceptor on get always deletes store contents
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-3693?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-3693:
--------------------------------
Description:
The activation interceptor when doing manual eviction always removes the entry from the loader on a get. This is done even if the entry is in the data container.
Now this is fine for a single invocation. However if a concurrent evict command comes on a different thread you can get in a state where the data is neither in the dc or loader defeating the purpose of Passivation.
The following describes this scenario
{code}
t1 -> calls get retrieves value from context (dc)
t2 -> calls evict retrieves value from context (dc)
t2 -> passivates entry (writes entry to loader)
t1 -> activates entry (removes entry from loader)
t2 -> removes entry from dc
{code}
Note this doesn't affect size based eviction.
was:
The activation interceptor when doing manual eviction always removes the entry from the loader on a get. This is done even if the entry is in the data container.
Now this is fine for a single invocation. However if a concurrent evict command comes on a different thread you can get in a state where the data is neither in the dc or loader defeating the purpose of Passivation.
The following describes this scenario
{code}
t1 -> calls get retrieves value from context (dc)
t2 -> calls evict retrieves value from context (dc)
t2 -> passivates entry (writes entry to loader)
t1 -> activates entry (removes entry from loader)
t2 -> removes entry from dc
{code}
Note this doesn't affect size based eviction.
Also looking closer we need to fix the act of activation. It can cause a window where no data is available between when the loader entry is removed and the data is committed to the data container. This would especially be apparent with tx caches as the data container wouldn't be updated until the tx is completed where as the loader is removed on the get.
Broke out second part to a second JIRA ISPN-3694
> ActivationInterceptor on get always deletes store contents
> ----------------------------------------------------------
>
> Key: ISPN-3693
> URL: https://issues.jboss.org/browse/ISPN-3693
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 6.0.0.CR1
> Reporter: William Burns
> Assignee: William Burns
> Priority: Blocker
> Fix For: 6.0.0.CR2
>
>
> The activation interceptor when doing manual eviction always removes the entry from the loader on a get. This is done even if the entry is in the data container.
> Now this is fine for a single invocation. However if a concurrent evict command comes on a different thread you can get in a state where the data is neither in the dc or loader defeating the purpose of Passivation.
> The following describes this scenario
> {code}
> t1 -> calls get retrieves value from context (dc)
> t2 -> calls evict retrieves value from context (dc)
> t2 -> passivates entry (writes entry to loader)
> t1 -> activates entry (removes entry from loader)
> t2 -> removes entry from dc
> {code}
> Note this doesn't affect size based eviction.
--
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, 5 months
[JBoss JIRA] (ISPN-3694) ActivationInterceptor when activating an entry has a gap of when no entry is available
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-3694?page=com.atlassian.jira.plugin.... ]
William Burns reassigned ISPN-3694:
-----------------------------------
Assignee: William Burns (was: Mircea Markus)
> ActivationInterceptor when activating an entry has a gap of when no entry is available
> --------------------------------------------------------------------------------------
>
> Key: ISPN-3694
> URL: https://issues.jboss.org/browse/ISPN-3694
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 6.0.0.CR1
> Reporter: William Burns
> Assignee: William Burns
> Fix For: 6.0.0.CR2
>
>
> The ActivationInterceptor currently attempts to remove entries from the cache store during the invocation of a get. However the actual committing of the data to the Data Container doesn't occur until the EntryWrappingInterceptor (non-tx) or when the CommitCommand (tx) is invoked, both of which is after the entry is removed from the loader. This can cause a momentary lapse where the entry is no longer in the data container or the loader. Also if you rolled back the tx containing the activation you would lose the entry completely.
--
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, 5 months
[JBoss JIRA] (ISPN-3694) ActivationInterceptor when activating an entry has a gap of when no entry is available
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-3694?page=com.atlassian.jira.plugin.... ]
Work on ISPN-3694 started by William Burns.
> ActivationInterceptor when activating an entry has a gap of when no entry is available
> --------------------------------------------------------------------------------------
>
> Key: ISPN-3694
> URL: https://issues.jboss.org/browse/ISPN-3694
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 6.0.0.CR1
> Reporter: William Burns
> Assignee: William Burns
> Fix For: 6.0.0.CR2
>
>
> The ActivationInterceptor currently attempts to remove entries from the cache store during the invocation of a get. However the actual committing of the data to the Data Container doesn't occur until the EntryWrappingInterceptor (non-tx) or when the CommitCommand (tx) is invoked, both of which is after the entry is removed from the loader. This can cause a momentary lapse where the entry is no longer in the data container or the loader. Also if you rolled back the tx containing the activation you would lose the entry completely.
--
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, 5 months
[JBoss JIRA] (ISPN-3694) ActivationInterceptor when activating an entry has a gap of when no entry is available
by William Burns (JIRA)
William Burns created ISPN-3694:
-----------------------------------
Summary: ActivationInterceptor when activating an entry has a gap of when no entry is available
Key: ISPN-3694
URL: https://issues.jboss.org/browse/ISPN-3694
Project: Infinispan
Issue Type: Bug
Components: Loaders and Stores
Affects Versions: 6.0.0.CR1
Reporter: William Burns
Assignee: Mircea Markus
Fix For: 6.0.0.CR2
The ActivationInterceptor currently attempts to remove entries from the cache store during the invocation of a get. However the actual committing of the data to the Data Container doesn't occur until the EntryWrappingInterceptor (non-tx) or when the CommitCommand (tx) is invoked, both of which is after the entry is removed from the loader. This can cause a momentary lapse where the entry is no longer in the data container or the loader. Also if you rolled back the tx containing the activation you would lose the entry completely.
--
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, 5 months
[JBoss JIRA] (ISPN-3693) ActivationInterceptor on get always deletes store contents
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-3693?page=com.atlassian.jira.plugin.... ]
William Burns reassigned ISPN-3693:
-----------------------------------
Assignee: William Burns (was: Mircea Markus)
> ActivationInterceptor on get always deletes store contents
> ----------------------------------------------------------
>
> Key: ISPN-3693
> URL: https://issues.jboss.org/browse/ISPN-3693
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 6.0.0.CR1
> Reporter: William Burns
> Assignee: William Burns
> Priority: Blocker
> Fix For: 6.0.0.CR2
>
>
> The activation interceptor when doing manual eviction always removes the entry from the loader on a get. This is done even if the entry is in the data container.
> Now this is fine for a single invocation. However if a concurrent evict command comes on a different thread you can get in a state where the data is neither in the dc or loader defeating the purpose of Passivation.
> The following describes this scenario
> {code}
> t1 -> calls get retrieves value from context (dc)
> t2 -> calls evict retrieves value from context (dc)
> t2 -> passivates entry (writes entry to loader)
> t1 -> activates entry (removes entry from loader)
> t2 -> removes entry from dc
> {code}
> Note this doesn't affect size based eviction.
> Also looking closer we need to fix the act of activation. It can cause a window where no data is available between when the loader entry is removed and the data is committed to the data container. This would especially be apparent with tx caches as the data container wouldn't be updated until the tx is completed where as the loader is removed on the get.
--
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, 5 months
[JBoss JIRA] (ISPN-3693) ActivationInterceptor on get always deletes store contents
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-3693?page=com.atlassian.jira.plugin.... ]
Work on ISPN-3693 started by William Burns.
> ActivationInterceptor on get always deletes store contents
> ----------------------------------------------------------
>
> Key: ISPN-3693
> URL: https://issues.jboss.org/browse/ISPN-3693
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 6.0.0.CR1
> Reporter: William Burns
> Assignee: William Burns
> Priority: Blocker
> Fix For: 6.0.0.CR2
>
>
> The activation interceptor when doing manual eviction always removes the entry from the loader on a get. This is done even if the entry is in the data container.
> Now this is fine for a single invocation. However if a concurrent evict command comes on a different thread you can get in a state where the data is neither in the dc or loader defeating the purpose of Passivation.
> The following describes this scenario
> {code}
> t1 -> calls get retrieves value from context (dc)
> t2 -> calls evict retrieves value from context (dc)
> t2 -> passivates entry (writes entry to loader)
> t1 -> activates entry (removes entry from loader)
> t2 -> removes entry from dc
> {code}
> Note this doesn't affect size based eviction.
> Also looking closer we need to fix the act of activation. It can cause a window where no data is available between when the loader entry is removed and the data is committed to the data container. This would especially be apparent with tx caches as the data container wouldn't be updated until the tx is completed where as the loader is removed on the get.
--
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, 5 months
[JBoss JIRA] (ISPN-3693) ActivationInterceptor on get always deletes store contents
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/ISPN-3693?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on ISPN-3693:
------------------------------------
I'm raising the priority of this - as if affects Wildfly, where passivation is used in our default configurations.
> ActivationInterceptor on get always deletes store contents
> ----------------------------------------------------------
>
> Key: ISPN-3693
> URL: https://issues.jboss.org/browse/ISPN-3693
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 6.0.0.CR1
> Reporter: William Burns
> Assignee: Mircea Markus
> Fix For: 6.0.0.CR2
>
>
> The activation interceptor when doing manual eviction always removes the entry from the loader on a get. This is done even if the entry is in the data container.
> Now this is fine for a single invocation. However if a concurrent evict command comes on a different thread you can get in a state where the data is neither in the dc or loader defeating the purpose of Passivation.
> The following describes this scenario
> {code}
> t1 -> calls get retrieves value from context (dc)
> t2 -> calls evict retrieves value from context (dc)
> t2 -> passivates entry (writes entry to loader)
> t1 -> activates entry (removes entry from loader)
> t2 -> removes entry from dc
> {code}
> Note this doesn't affect size based eviction.
> Also looking closer we need to fix the act of activation. It can cause a window where no data is available between when the loader entry is removed and the data is committed to the data container. This would especially be apparent with tx caches as the data container wouldn't be updated until the tx is completed where as the loader is removed on the get.
--
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, 5 months
[JBoss JIRA] (ISPN-3693) ActivationInterceptor on get always deletes store contents
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/ISPN-3693?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated ISPN-3693:
-------------------------------
Priority: Blocker (was: Major)
> ActivationInterceptor on get always deletes store contents
> ----------------------------------------------------------
>
> Key: ISPN-3693
> URL: https://issues.jboss.org/browse/ISPN-3693
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 6.0.0.CR1
> Reporter: William Burns
> Assignee: Mircea Markus
> Priority: Blocker
> Fix For: 6.0.0.CR2
>
>
> The activation interceptor when doing manual eviction always removes the entry from the loader on a get. This is done even if the entry is in the data container.
> Now this is fine for a single invocation. However if a concurrent evict command comes on a different thread you can get in a state where the data is neither in the dc or loader defeating the purpose of Passivation.
> The following describes this scenario
> {code}
> t1 -> calls get retrieves value from context (dc)
> t2 -> calls evict retrieves value from context (dc)
> t2 -> passivates entry (writes entry to loader)
> t1 -> activates entry (removes entry from loader)
> t2 -> removes entry from dc
> {code}
> Note this doesn't affect size based eviction.
> Also looking closer we need to fix the act of activation. It can cause a window where no data is available between when the loader entry is removed and the data is committed to the data container. This would especially be apparent with tx caches as the data container wouldn't be updated until the tx is completed where as the loader is removed on the get.
--
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, 5 months