[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=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=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=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=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=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=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)
