You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ignite.apache.org by "Maxim Muzafarov (Jira)" <ji...@apache.org> on 2020/06/02 19:10:00 UTC

[jira] [Assigned] (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:all-tabpanel ]

Maxim Muzafarov reassigned IGNITE-4029:
---------------------------------------

    Assignee: Maxim Muzafarov  (was: Nikolay Tikhonov)

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