[ 
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)

Reply via email to