[ https://issues.apache.org/jira/browse/IGNITE-7692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sergey Chugunov reassigned IGNITE-7692: --------------------------------------- Assignee: Sergey Chugunov > 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 > Assignee: Sergey Chugunov > Priority: Major > Labels: MakeTeamcityGreenAgain, Muted_test, 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)