[jira] [Commented] (IGNITE-4029) Local ContinuousQueries on PARTITIONED caches may await for previously rejected events
[ https://issues.apache.org/jira/browse/IGNITE-4029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17192417#comment-17192417 ] Maxim Muzafarov commented on IGNITE-4029: - [~b0z02003] Does this issue still actual for you? > Local ContinuousQueries on PARTITIONED caches may await for previously > rejected events > -- > > Key: IGNITE-4029 > URL: https://issues.apache.org/jira/browse/IGNITE-4029 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 1.7, 1.8 >Reporter: David Bidorff >Assignee: Maxim Muzafarov >Priority: Major > Attachments: Ignite4029Test.java > > > {{CacheContinuousQueryHandler.PartitionRecovery.collectEntries()}} stores and > updates the identifier of the next expected event. However, some events may > be rejected before even reaching the query handler, preventing this counter > to be incremented and leading the next events to be queued until > {{MAX_BUFF_SIZE}} is reached. > This happens after data was rebalanced: some events may be handled as > happening on a backup node, leading the test {{primary || skipPrimaryCheck}} > (on line 410 of {{CacheContinuousQueryHandler.onEntryUpdate()}}) to be false > and preventing the previously mentioned counter to be increased. > I'm not sure if the main problem is about those events being considered has > happening on a backup node or if it is about the counter not being > incremented, but either way, this can be problematic on caches with very few > 'update events' where the {{MAX_BUFF_SIZE}} is not reached quickly. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-4029) Local ContinuousQueries on PARTITIONED caches may await for previously rejected events
[ https://issues.apache.org/jira/browse/IGNITE-4029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17192416#comment-17192416 ] Maxim Muzafarov commented on IGNITE-4029: - Currently, I can reproduce the issue (attached reproducer passes locally on my environment). Seems something has been fixed. > Local ContinuousQueries on PARTITIONED caches may await for previously > rejected events > -- > > Key: IGNITE-4029 > URL: https://issues.apache.org/jira/browse/IGNITE-4029 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 1.7, 1.8 >Reporter: David Bidorff >Assignee: Maxim Muzafarov >Priority: Major > Attachments: Ignite4029Test.java > > > {{CacheContinuousQueryHandler.PartitionRecovery.collectEntries()}} stores and > updates the identifier of the next expected event. However, some events may > be rejected before even reaching the query handler, preventing this counter > to be incremented and leading the next events to be queued until > {{MAX_BUFF_SIZE}} is reached. > This happens after data was rebalanced: some events may be handled as > happening on a backup node, leading the test {{primary || skipPrimaryCheck}} > (on line 410 of {{CacheContinuousQueryHandler.onEntryUpdate()}}) to be false > and preventing the previously mentioned counter to be increased. > I'm not sure if the main problem is about those events being considered has > happening on a backup node or if it is about the counter not being > incremented, but either way, this can be problematic on caches with very few > 'update events' where the {{MAX_BUFF_SIZE}} is not reached quickly. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-4029) Local ContinuousQueries on PARTITIONED caches may await for previously rejected events
[ https://issues.apache.org/jira/browse/IGNITE-4029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15887807#comment-15887807 ] Nikolay Tikhonov commented on IGNITE-4029: -- [~b0z02003] Sounds weird. I'm looking on it. > Local ContinuousQueries on PARTITIONED caches may await for previously > rejected events > -- > > Key: IGNITE-4029 > URL: https://issues.apache.org/jira/browse/IGNITE-4029 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 1.7, 1.8 >Reporter: David Bidorff > Attachments: TestIgnite4029.java > > > {{CacheContinuousQueryHandler.PartitionRecovery.collectEntries()}} stores and > updates the identifier of the next expected event. However, some events may > be rejected before even reaching the query handler, preventing this counter > to be incremented and leading the next events to be queued until > {{MAX_BUFF_SIZE}} is reached. > This happens after data was rebalanced: some events may be handled as > happening on a backup node, leading the test {{primary || skipPrimaryCheck}} > (on line 410 of {{CacheContinuousQueryHandler.onEntryUpdate()}}) to be false > and preventing the previously mentioned counter to be increased. > I'm not sure if the main problem is about those events being considered has > happening on a backup node or if it is about the counter not being > incremented, but either way, this can be problematic on caches with very few > 'update events' where the {{MAX_BUFF_SIZE}} is not reached quickly. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IGNITE-4029) Local ContinuousQueries on PARTITIONED caches may await for previously rejected events
[ https://issues.apache.org/jira/browse/IGNITE-4029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15887641#comment-15887641 ] David Bidorff commented on IGNITE-4029: --- >From what I saw when writing this test, it seems that the behavior is >different when the CacheAtomicityMode is set to ATOMIC: the first cache seems >to be "catching up" (the ContinuousQuery processes all of the previously >stored values of the key) when the remote node is stopped. Is that an expected >behavior ? > Local ContinuousQueries on PARTITIONED caches may await for previously > rejected events > -- > > Key: IGNITE-4029 > URL: https://issues.apache.org/jira/browse/IGNITE-4029 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 1.7, 1.8 >Reporter: David Bidorff > Attachments: TestIgnite4029.java > > > {{CacheContinuousQueryHandler.PartitionRecovery.collectEntries()}} stores and > updates the identifier of the next expected event. However, some events may > be rejected before even reaching the query handler, preventing this counter > to be incremented and leading the next events to be queued until > {{MAX_BUFF_SIZE}} is reached. > This happens after data was rebalanced: some events may be handled as > happening on a backup node, leading the test {{primary || skipPrimaryCheck}} > (on line 410 of {{CacheContinuousQueryHandler.onEntryUpdate()}}) to be false > and preventing the previously mentioned counter to be increased. > I'm not sure if the main problem is about those events being considered has > happening on a backup node or if it is about the counter not being > incremented, but either way, this can be problematic on caches with very few > 'update events' where the {{MAX_BUFF_SIZE}} is not reached quickly. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IGNITE-4029) Local ContinuousQueries on PARTITIONED caches may await for previously rejected events
[ https://issues.apache.org/jira/browse/IGNITE-4029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15886141#comment-15886141 ] Nikolay Tikhonov commented on IGNITE-4029: -- [~b0z02003], Do you have reproducible test on this behaviour? > Local ContinuousQueries on PARTITIONED caches may await for previously > rejected events > -- > > Key: IGNITE-4029 > URL: https://issues.apache.org/jira/browse/IGNITE-4029 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 1.7, 1.8 >Reporter: David Bidorff > > {{CacheContinuousQueryHandler.PartitionRecovery.collectEntries()}} stores and > updates the identifier of the next expected event. However, some events may > be rejected before even reaching the query handler, preventing this counter > to be incremented and leading the next events to be queued until > {{MAX_BUFF_SIZE}} is reached. > This happens after data was rebalanced: some events may be handled as > happening on a backup node, leading the test {{primary || skipPrimaryCheck}} > (on line 410 of {{CacheContinuousQueryHandler.onEntryUpdate()}}) to be false > and preventing the previously mentioned counter to be increased. > I'm not sure if the main problem is about those events being considered has > happening on a backup node or if it is about the counter not being > incremented, but either way, this can be problematic on caches with very few > 'update events' where the {{MAX_BUFF_SIZE}} is not reached quickly. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IGNITE-4029) Local ContinuousQueries on PARTITIONED caches may await for previously rejected events
[ https://issues.apache.org/jira/browse/IGNITE-4029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15548228#comment-15548228 ] David Bidorff commented on IGNITE-4029: --- I believe this issue was caused by this task, which seems to be where the per-partition update counter was implemented. > Local ContinuousQueries on PARTITIONED caches may await for previously > rejected events > -- > > Key: IGNITE-4029 > URL: https://issues.apache.org/jira/browse/IGNITE-4029 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 1.7 >Reporter: David Bidorff >Priority: Minor > > {{CacheContinuousQueryHandler.PartitionRecovery.collectEntries()}} stores and > updates the identifier of the next expected event. However, some events may > be rejected before even reaching the query handler, preventing this counter > to be incremented and leading the next events to be queued until > {{MAX_BUFF_SIZE}} is reached. > This happens after data was rebalanced: some events may be handled as > happening on a backup node, leading the test {{primary || skipPrimaryCheck}} > (on line 410 of {{CacheContinuousQueryHandler.onEntryUpdate()}}) to be false > and preventing the previously mentioned counter to be increased. > I'm not sure if the main problem is about those events being considered has > happening on a backup node or if it is about the counter not being > incremented, but either way, this can be problematic on caches with very few > 'update events' where the {{MAX_BUFF_SIZE}} is not reached quickly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)