[jira] [Commented] (IGNITE-4029) Local ContinuousQueries on PARTITIONED caches may await for previously rejected events

2020-09-08 Thread Maxim Muzafarov (Jira)


[ 
https://issues.apache.org/jira/browse/IGNITE-4029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17192417#comment-17192417
 ] 

Maxim Muzafarov commented on IGNITE-4029:
-

[~b0z02003] Does this issue still actual for you?

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


[jira] [Commented] (IGNITE-4029) Local ContinuousQueries on PARTITIONED caches may await for previously rejected events

2020-09-08 Thread Maxim Muzafarov (Jira)


[ 
https://issues.apache.org/jira/browse/IGNITE-4029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17192416#comment-17192416
 ] 

Maxim Muzafarov commented on IGNITE-4029:
-

Currently, I can reproduce the issue (attached reproducer passes locally on my 
environment).
Seems something has been fixed.

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


[jira] [Commented] (IGNITE-4029) Local ContinuousQueries on PARTITIONED caches may await for previously rejected events

2017-02-28 Thread Nikolay Tikhonov (JIRA)

[ 
https://issues.apache.org/jira/browse/IGNITE-4029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15887807#comment-15887807
 ] 

Nikolay Tikhonov commented on IGNITE-4029:
--

[~b0z02003]
Sounds weird. I'm looking on it.

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


[jira] [Commented] (IGNITE-4029) Local ContinuousQueries on PARTITIONED caches may await for previously rejected events

2017-02-28 Thread David Bidorff (JIRA)

[ 
https://issues.apache.org/jira/browse/IGNITE-4029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15887641#comment-15887641
 ] 

David Bidorff commented on IGNITE-4029:
---

>From what I saw when writing this test, it seems that the behavior is 
>different when the CacheAtomicityMode is set to ATOMIC: the first cache seems 
>to be "catching up" (the ContinuousQuery processes all of the previously 
>stored values of the key) when the remote node is stopped. Is that an expected 
>behavior ?

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


[jira] [Commented] (IGNITE-4029) Local ContinuousQueries on PARTITIONED caches may await for previously rejected events

2017-02-27 Thread Nikolay Tikhonov (JIRA)

[ 
https://issues.apache.org/jira/browse/IGNITE-4029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15886141#comment-15886141
 ] 

Nikolay Tikhonov commented on IGNITE-4029:
--

[~b0z02003],
Do you have reproducible test on this behaviour?

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


[jira] [Commented] (IGNITE-4029) Local ContinuousQueries on PARTITIONED caches may await for previously rejected events

2016-10-05 Thread David Bidorff (JIRA)

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