[
https://issues.apache.org/jira/browse/OAK-5995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15994289#comment-15994289
]
Chetan Mehrotra commented on OAK-5995:
--------------------------------------
bq. It looks like the customer setup the pre production instance without
clearing the local FS copy of the index so Lucene was working the wrong files
and had issues with that.
Good to know. This would be handled better in Oak 1.6 with fix for OAK-4114
which would ensure that local index copy if purged if there is any mismatch
between index files on local dir and one in NodeStore
> Lucene indexing with copyonread/write holding unexpectedly much files open
> --------------------------------------------------------------------------
>
> Key: OAK-5995
> URL: https://issues.apache.org/jira/browse/OAK-5995
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
> Affects Versions: 1.4.1
> Reporter: Dirk Rudolph
> Assignee: Chetan Mehrotra
> Attachments: lsofout2.txt
>
>
> We recently faced the issue that our Oak based enterprise content management
> system run into failures due to too much open files. Monitoring the lsof
> output we found out that most of the opened files of the process are the
> files within the configured localIndexDir of the LuceneIndexProviderService.
> {code}
> enableCopyOnReadSupport="true"
> localIndexDir="tmp/index"
> enableCopyOnWriteSupport="true"
> {code}
> See attached the lsof output:
> {code}
> ~ wc -l lsofout2.txt
> 20388 lsofout2.txt
> ~ grep "tmp/index" lsofout2.txt | wc -l
> 13499
> {code}
> where more then 60% of open files are "tmp/index" ones as configured as
> {{localIndexDir}} shortly after a restart of the process.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
