[JBoss JIRA] (ISPN-3830) Conditional Operation can fail erroneously during ST
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3830?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-3830:
------------------------------------
This is related to my fix for ISPN-3422.
> Conditional Operation can fail erroneously during ST
> ----------------------------------------------------
>
> Key: ISPN-3830
> URL: https://issues.jboss.org/browse/ISPN-3830
> Project: Infinispan
> Issue Type: Bug
> Components: State transfer
> Reporter: William Burns
> Assignee: Dan Berindei
>
> Currently the retry logic for commands is to only throw a OutdatedTopologyException when a command is successful.
> This however can have the following issue.
> k1 owned by N1, N2
> # N3 updates k1 sending conditional command to N1
> # N1 receives command and starts running it (passes topology block)
> # ST occurs causing N1 to no longer be an owner and removes k1 from it's data container.
> # N1 runs optional command and it fails and thus doesn't throw OutdatedTopologyException
> # N3 gets response that command failed, but it could have worked had it gone to a real owner.
--
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
11 years
[JBoss JIRA] (ISPN-3830) Conditional Operation can fail erroneously during ST
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3830?page=com.atlassian.jira.plugin.... ]
Dan Berindei reassigned ISPN-3830:
----------------------------------
Assignee: Dan Berindei (was: Mircea Markus)
> Conditional Operation can fail erroneously during ST
> ----------------------------------------------------
>
> Key: ISPN-3830
> URL: https://issues.jboss.org/browse/ISPN-3830
> Project: Infinispan
> Issue Type: Bug
> Components: State transfer
> Reporter: William Burns
> Assignee: Dan Berindei
>
> Currently the retry logic for commands is to only throw a OutdatedTopologyException when a command is successful.
> This however can have the following issue.
> k1 owned by N1, N2
> # N3 updates k1 sending conditional command to N1
> # N1 receives command and starts running it (passes topology block)
> # ST occurs causing N1 to no longer be an owner and removes k1 from it's data container.
> # N1 runs optional command and it fails and thus doesn't throw OutdatedTopologyException
> # N3 gets response that command failed, but it could have worked had it gone to a real owner.
--
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
11 years
[JBoss JIRA] (ISPN-3829) Null value read with RR can be replaced by cache loader value
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-3829?page=com.atlassian.jira.plugin.... ]
William Burns commented on ISPN-3829:
-------------------------------------
ISPN-3797 will fix this in a better fashion. However we may have to fix this for a version Infinispan 6
> Null value read with RR can be replaced by cache loader value
> -------------------------------------------------------------
>
> Key: ISPN-3829
> URL: https://issues.jboss.org/browse/ISPN-3829
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 6.0.0.Final
> Reporter: William Burns
> Assignee: Mircea Markus
>
> Currently the CacheLoaderInterceptor does the following check to determine if it should check the loader for a value
> {code}
> if (e == null || e.isNull() || e.getValue() == null) {
> {code}
> Unfortunately this means it checks the loader when a null value is in the entry when using RR. This can cause an issue if another transaction commits that key and puts a value that results in that value being inserted into the loader.
> This also is a performance issue for RR, since it has to check the loader over and over for a given key even if it was found null the first time.
> Initial thought is to do something like setSkipRemoteGet and that could actually be used for a dual purpose possibly.
--
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
11 years
[JBoss JIRA] (ISPN-3830) Conditional Operation can fail erroneously during ST
by William Burns (JIRA)
William Burns created ISPN-3830:
-----------------------------------
Summary: Conditional Operation can fail erroneously during ST
Key: ISPN-3830
URL: https://issues.jboss.org/browse/ISPN-3830
Project: Infinispan
Issue Type: Bug
Components: State transfer
Reporter: William Burns
Assignee: Mircea Markus
Currently the retry logic for commands is to only throw a OutdatedTopologyException when a command is successful.
This however can have the following issue.
k1 owned by N1, N2
# N3 updates k1 sending conditional command to N1
# N1 receives command and starts running it (passes topology block)
# ST occurs causing N1 to no longer be an owner and removes k1 from it's data container.
# N1 runs optional command and it fails and thus doesn't throw OutdatedTopologyException
# N3 gets response that command failed, but it could have worked had it gone to a real owner.
--
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
11 years