[
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
(v6.3.15#6346)
