[
https://issues.apache.org/jira/browse/IGNITE-7692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-7692:
-------------------------------------
Labels: usability (was: )
> affinityCall and affinityRun may execute code on backup partitions
> ------------------------------------------------------------------
>
> Key: IGNITE-7692
> URL: https://issues.apache.org/jira/browse/IGNITE-7692
> Project: Ignite
> Issue Type: Bug
> Components: sql
> Affects Versions: 2.1
> Reporter: Alexey Goncharuk
> Priority: Major
> Labels: usability
> Fix For: 2.5
>
>
> Apparently, the affinityCall and affinityRun methods reserve partitions and
> check their state to be OWNING, however, if topology changes and partition
> role is changed to backup from primary, the code is still executed.
> This can be an issue if a user executes a local SQL query inside the
> affinityCall runnable. In this case, the query result may return null.
> This can be observed in the
> IgniteCacheLockPartitionOnAffinityRunTest#getPersonsCountSingleCache - note
> an additional check I've added to make the test pass.
> I think it is ok to have an old semantics for the API, because in some cases
> (scan query, local gets) a backup OWNER is enough. However, it looks like we
> need to add another API method to enforce that affinity run be executed on
> primary nodes and forbid primary role change.
> Another option is to detect a topology version of the affinity run and use
> that version for local SQL queries.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
