[jira] [Updated] (IGNITE-12618) Affinity cache for version of last server event can be wiped from history
[ https://issues.apache.org/jira/browse/IGNITE-12618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-12618: - Fix Version/s: 2.8.1 > Affinity cache for version of last server event can be wiped from history > - > > Key: IGNITE-12618 > URL: https://issues.apache.org/jira/browse/IGNITE-12618 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.8 >Reporter: Vyacheslav Koptilin >Assignee: Vyacheslav Koptilin >Priority: Major > Fix For: 2.9, 2.8.1 > > Time Spent: 20m > Remaining Estimate: 0h > > After IGNITE-11465 implemented, there's still a corner case when we can get > "Getting affinity for topology version earlier than affinity is calculated" > error. > If the whole history (not more than > GridAffinityAssignmentCache#MAX_HIST_LINKS_SIZE entries) consists of shallow > copies for client events, we may be not able to fetch affinity cache for last > affinity change version. > We need to make GridAffinityAssignmentCache#cachedAffinity work if affinity > version no less than [last affinity change version] is passed as an argument. > *UPDATE* > GridAffinityProcessor#affMap and GridAffinityAssignmentCache#affCache store > objects for every topology version (within history range). Mappings inside > are only shallow copies of each other, but corner-case, when cluster > experiences unlimited client / local cache topology events, will still cause > OOM - at least two reference objects are created for each topology version. > We can't store a fixed number of entries either. The best solution would be > not storing instances for client events at all. This may require severe > refactoring of affinity assignment related logic. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12618) Affinity cache for version of last server event can be wiped from history
[ https://issues.apache.org/jira/browse/IGNITE-12618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-12618: - Description: After IGNITE-11465 implemented, there's still a corner case when we can get "Getting affinity for topology version earlier than affinity is calculated" error. If the whole history (not more than GridAffinityAssignmentCache#MAX_HIST_LINKS_SIZE entries) consists of shallow copies for client events, we may be not able to fetch affinity cache for last affinity change version. We need to make GridAffinityAssignmentCache#cachedAffinity work if affinity version no less than [last affinity change version] is passed as an argument. *UPDATE* GridAffinityProcessor#affMap and GridAffinityAssignmentCache#affCache store objects for every topology version (within history range). Mappings inside are only shallow copies of each other, but corner-case, when cluster experiences unlimited client / local cache topology events, will still cause OOM - at least two reference objects are created for each topology version. We can't store a fixed number of entries either. The best solution would be not storing instances for client events at all. This may require severe refactoring of affinity assignment related logic. was: After IGNITE-11465 implemented, there's still a corner case when we can get "Getting affinity for topology version earlier than affinity is calculated" error. If the whole history (not more than GridAffinityAssignmentCache#MAX_HIST_LINKS_SIZE entries) consists of shallow copies for client events, we may be not able to fetch affinity cache for last affinity change version. We need to make GridAffinityAssignmentCache#cachedAffinity work if affinity version no less than [last affinity change version] is passed as an argument. > Affinity cache for version of last server event can be wiped from history > - > > Key: IGNITE-12618 > URL: https://issues.apache.org/jira/browse/IGNITE-12618 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.8 >Reporter: Vyacheslav Koptilin >Assignee: Vyacheslav Koptilin >Priority: Major > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > After IGNITE-11465 implemented, there's still a corner case when we can get > "Getting affinity for topology version earlier than affinity is calculated" > error. > If the whole history (not more than > GridAffinityAssignmentCache#MAX_HIST_LINKS_SIZE entries) consists of shallow > copies for client events, we may be not able to fetch affinity cache for last > affinity change version. > We need to make GridAffinityAssignmentCache#cachedAffinity work if affinity > version no less than [last affinity change version] is passed as an argument. > *UPDATE* > GridAffinityProcessor#affMap and GridAffinityAssignmentCache#affCache store > objects for every topology version (within history range). Mappings inside > are only shallow copies of each other, but corner-case, when cluster > experiences unlimited client / local cache topology events, will still cause > OOM - at least two reference objects are created for each topology version. > We can't store a fixed number of entries either. The best solution would be > not storing instances for client events at all. This may require severe > refactoring of affinity assignment related logic. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12618) Affinity cache for version of last server event can be wiped from history
[ https://issues.apache.org/jira/browse/IGNITE-12618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-12618: - Description: After IGNITE-11465 implemented, there's still a corner case when we can get "Getting affinity for topology version earlier than affinity is calculated" error. If the whole history (not more than GridAffinityAssignmentCache#MAX_HIST_LINKS_SIZE entries) consists of shallow copies for client events, we may be not able to fetch affinity cache for last affinity change version. We need to make GridAffinityAssignmentCache#cachedAffinity work if affinity version no less than [last affinity change version] is passed as an argument. was: After IGNITE-11465 RESOLVED implemented, there's still a corner case when we can get "Getting affinity for topology version earlier than affinity is calculated" error. If the whole history (not more than GridAffinityAssignmentCache#MAX_HIST_LINKS_SIZE entries) consists of shallow copies for client events, we may be not able to fetch affinity cache for last affinity change version. We need to make GridAffinityAssignmentCache#cachedAffinity work if affinity version no less than [last affinity change version] is passed as an argument. > Affinity cache for version of last server event can be wiped from history > - > > Key: IGNITE-12618 > URL: https://issues.apache.org/jira/browse/IGNITE-12618 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.8 >Reporter: Vyacheslav Koptilin >Assignee: Vyacheslav Koptilin >Priority: Major > Fix For: 2.9 > > > After IGNITE-11465 implemented, there's still a corner case when we can get > "Getting affinity for topology version earlier than affinity is calculated" > error. > If the whole history (not more than > GridAffinityAssignmentCache#MAX_HIST_LINKS_SIZE entries) consists of shallow > copies for client events, we may be not able to fetch affinity cache for last > affinity change version. > We need to make GridAffinityAssignmentCache#cachedAffinity work if affinity > version no less than [last affinity change version] is passed as an argument. -- This message was sent by Atlassian Jira (v8.3.4#803005)
