jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Eissing (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (OAK-5368) Not configurable/Unnecessary short Lucene Observation Queue length
Date Fri, 23 Dec 2016 09:28:58 GMT

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

Stefan Eissing commented on OAK-5368:

[~chetanm] I agree that it will work for the compacted changes and it always recovers quite
fast in my tests. If it has performance impact I cannot say, since I investigate other, larger
performance blocks. I mainly want to clear the error logs from things that are not relevant
warnings and give a notice that a length of 5 is not realistic for a busy server.

I think, if it weren't for reusing the BackgroundObserver, a queue length of 1 would be fine
where the producer always replaces any existing change with a new, info=null instance. Which
goes into queue compaction strategies,

For this ticket, if we could eliminate the unnecessary warning, I'd be good.

> Not configurable/Unnecessary short Lucene Observation Queue length
> ------------------------------------------------------------------
>                 Key: OAK-5368
>                 URL: https://issues.apache.org/jira/browse/OAK-5368
>             Project: Jackrabbit Oak
>          Issue Type: Improvement
>          Components: lucene
>    Affects Versions: 1.4.10
>            Reporter: Stefan Eissing
>            Assignee: Chetan Mehrotra
>            Priority: Minor
>             Fix For: 1.8
>         Attachments: LuceneIndexConfigObserver-under-load.png
> The maximum queue length in the {{LuceneIndexConfigObserver}} is hard coded to 5. This
is unreasonable short for production systems experiencing heavy load.
> Tests with a patched version resulted in observed queue length of >100 entries. This
floods warnings into the error log, produces additional load.
> The fix would be to increase the queue max, make it configurable or rely on the system
default (which can be configured).

This message was sent by Atlassian JIRA

View raw message