[jira] [Commented] (OAK-5626) ChangeProcessor doesn't reset 'blocking' flag when items from queue gets removed and commit-rate-limiter is null

["Stefan Egli (JIRA)" <ji...@apache.org>]

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

Stefan Egli commented on OAK-5626:
----------------------------------

bq. My concern is that this would lead to almost every commit leading to those WARN flooding the logs.
Agreed, I had the same thought.
bq. But, this part lies in fairly critical section - I'm not sure of getting time can be expensive or not?
Agreed, not sure if it's a problem though.
But one possible alternative might be to move the time check to the [{{removed()}}|https://github.com/apache/jackrabbit-oak/blob/4eac76dcbb262f10af9202cdcbc3e95dee40107a/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/observation/ChangeProcessor.java#L303] case. It would get a bit unprecise and more tricky to implement, but {{removed()}} is called asynchronously and therefore less time critical.

So above could be eg implemented "modCnt" style using {{logCnt}}, {{suppressCnt}} and {{lastSuppressTime}} as follows: 
* {{logCnt}} tracks number of those log.warns and log.warn is only issued if {{logCnt<=suppressCnt}}, in which case it then does {{logCnt = suppressCnt + 1}} (thus logCnt is maintained by the "add" thread only)
* the "remove" thread takes note of logCnt incrementing, measures time ({{lastSuppressTime}}), and would increment suppressCnt only after eg 5min (so time is only ever checked in the remove thread). 

Not super nice, but possible

> ChangeProcessor doesn't reset 'blocking' flag when items from queue gets removed and commit-rate-limiter is null
> ----------------------------------------------------------------------------------------------------------------
>
>                 Key: OAK-5626
>                 URL: https://issues.apache.org/jira/browse/OAK-5626
>             Project: Jackrabbit Oak
>          Issue Type: Bug
>          Components: core
>            Reporter: Vikas Saurabh
>            Assignee: Vikas Saurabh
>            Priority: Minor
>
> Following up on conversation at \[0]:
> {{ChangeProcessor#queueSizeChanged}} \[1] sets blocking flag to true if queue
> size is hit (or beyond). The warning "Revision queue is full. Further
> revisions will be compacted." is logged only when it *wasn't*
> blocking.
> BUT, when queue empties, blocking flag is reset inside if block for
> commitRateLimiter!=null. That means an event chain like: 
> # qFull
> # log warn
> # qEmpties
> # qFull 
> won't log the WARN after step(4)
> \[0]: http://markmail.org/message/hgein5g3ohyjhw5n
> \[1]: https://github.com/apache/jackrabbit-oak/blob/trunk/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/observation/ChangeProcessor.java#L307



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)