[jira] [Updated] (IGNITE-7692) affinityCall and affinityRun may execute code on backup partitions
[ https://issues.apache.org/jira/browse/IGNITE-7692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-7692: Fix Version/s: (was: 2.10) > 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: cache >Affects Versions: 2.1 >Reporter: Alexey Goncharuk >Assignee: Sergey Chugunov >Priority: Major > Labels: MakeTeamcityGreenAgain, Muted_test, usability > > 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 (v8.3.4#803005)
[jira] [Updated] (IGNITE-7692) affinityCall and affinityRun may execute code on backup partitions
[ https://issues.apache.org/jira/browse/IGNITE-7692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-7692: -- Fix Version/s: (was: 2.9) 2.10 > 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: cache >Affects Versions: 2.1 >Reporter: Alexey Goncharuk >Assignee: Sergey Chugunov >Priority: Major > Labels: MakeTeamcityGreenAgain, Muted_test, usability > Fix For: 2.10 > > > 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 (v8.3.4#803005)
[jira] [Updated] (IGNITE-7692) affinityCall and affinityRun may execute code on backup partitions
[ https://issues.apache.org/jira/browse/IGNITE-7692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-7692: Fix Version/s: (was: 2.8) 2.9 > 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: cache >Affects Versions: 2.1 >Reporter: Alexey Goncharuk >Assignee: Sergey Chugunov >Priority: Major > Labels: MakeTeamcityGreenAgain, Muted_test, usability > Fix For: 2.9 > > > 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 (v8.3.4#803005)
[jira] [Updated] (IGNITE-7692) affinityCall and affinityRun may execute code on backup partitions
[ https://issues.apache.org/jira/browse/IGNITE-7692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-7692: Component/s: cache > 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: cache >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 (v7.6.3#76005)
[jira] [Updated] (IGNITE-7692) affinityCall and affinityRun may execute code on backup partitions
[ 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 (v7.6.3#76005)
[jira] [Updated] (IGNITE-7692) affinityCall and affinityRun may execute code on backup partitions
[ https://issues.apache.org/jira/browse/IGNITE-7692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-7692: - Fix Version/s: (was: 2.7) 2.8 > 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.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 (v7.6.3#76005)
[jira] [Updated] (IGNITE-7692) affinityCall and affinityRun may execute code on backup partitions
[ https://issues.apache.org/jira/browse/IGNITE-7692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-7692: --- Fix Version/s: (was: 2.6) 2.7 > 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.7 > > > 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)
[jira] [Updated] (IGNITE-7692) affinityCall and affinityRun may execute code on backup partitions
[ https://issues.apache.org/jira/browse/IGNITE-7692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-7692: - Fix Version/s: (was: 2.5) 2.6 > 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.6 > > > 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)
[jira] [Updated] (IGNITE-7692) affinityCall and affinityRun may execute code on backup partitions
[ https://issues.apache.org/jira/browse/IGNITE-7692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-7692: --- Labels: MakeTeamcityGreenAgain Muted_test usability (was: usability) > 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: 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)
[jira] [Updated] (IGNITE-7692) affinityCall and affinityRun may execute code on backup partitions
[ https://issues.apache.org/jira/browse/IGNITE-7692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-7692: - Component/s: 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 > 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)
[jira] [Updated] (IGNITE-7692) affinityCall and affinityRun may execute code on backup partitions
[ 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)
