ignite-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vladimir Ozerov (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (IGNITE-7692) affinityCall and affinityRun may execute code on backup partitions
Date Thu, 14 Feb 2019 14:31:00 GMT

     [ https://issues.apache.org/jira/browse/IGNITE-7692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Vladimir Ozerov updated IGNITE-7692:
    Component/s:     (was: sql)

> 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
>    Affects Versions: 2.1
>            Reporter: Alexey Goncharuk
>            Assignee: Sergey Chugunov
>            Priority: Major
>              Labels: MakeTeamcityGreenAgain, Muted_test, usability
>             Fix For: 2.8
> 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

View raw message