Issue created with the lsof output attached here: https://issues.apache.org/jira/browse/OAK-5995 <https://issues.apache.org/jira/browse/OAK-5995>
Thanks for the input. As far as we know, we properly close sessions where ever we open them. Additionally I don’t understand why open sessions should keep index files open? Nor do we handle those files ourself, or even accessing classes of oak-lucene from our codebase. So from my perspective its not the application code causing that, though it might be the enterprise content management system. Cheers Dirk Rudolph | Senior Software Engineer Netcentric AG M: +41 79 642 07 99 [email protected] <mailto:[email protected]> | www.netcentric.biz <http://www.netcentric.biz/> > On 28 Mar 2017, at 16:20, Clay Ferguson <[email protected]> wrote: > > This type of problem, is most often caused by failing to put close() calls > in 'finally blocks'. All resource management in Java always needs to > handled in finally blocks, or else resource leaks can easily bring a server > down from memory or handles issues. There may be places in Oak source that > isn't doing this, IDK. Of course the other possibility Dirk is that your > own code may not even be calling close() on everything it needs to. > > Also same is true for session.logout(). Make sure you aren't holding open a > bunch of sessions at once (like on multiple threads, or just from failing > to call logout() in some loop that does processing). And finally make sure > when you process large batches of operations that you don't build up too > many changes before doing a commit. session.save(). I have heard of apps > having problems in the past simply by trying to do too much in the same > "commit". > > > Best regards, > Clay Ferguson > [email protected] > > > On Tue, Mar 28, 2017 at 9:00 AM, Dirk Rudolph <[email protected]> > wrote: > >> Hi, >> >> 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. We have copyonread and copyonwrite enabled. >> >> Are there any know limitations with handling open files related to those 2 >> options? If so, I naively would expect the implementation to manage file >> handles following kind of a LRU pattern and to allow configuring a maximum >> amount of file handles to use. >> >> Talking in numbers we have, after a fresh restart of the process about 20k >> open files, 13k are index files, 2.5k segmentstore and most of the others >> jar files. The ulimit is already set to more then 65k but the instance >> crashed with more then 75k open file handles. >> >> Many thanks in advance, >> >> /Dirk >> >> >>
