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