ignite-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Bidorff (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (IGNITE-4029) Local ContinuousQueries on PARTITIONED caches may await for previously rejected events
Date Wed, 01 Mar 2017 09:16:45 GMT

     [ https://issues.apache.org/jira/browse/IGNITE-4029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

David Bidorff updated IGNITE-4029:
    Attachment: Ignite4029Test.java

So, the more I look into my tests, the weirder it gets. I updated my tests (and provided it
as an attachment to this ticket) and it seems that the order of the nodes startup is important
* If node A is started before node B, then test succeeds every time.
* If node B is started before node A, then test fails every time.

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

View raw message