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 Tue, 28 Feb 2017 09:15: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: TestIgnite4029.java

So, this is not a proper test, but it is simple enough to reproduce my issue :
# 2 nodes are started with a local ContinuousQuery that will print any value stored into the
cache on each.
# on the first node, I store a counter whose affinity is with the second node.
# when that counter reaches 5, I close the second node and I expect the ContinuousQuery of
the first node to take over, but it does not.

> 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

View raw message