|
That comment doesn't indicate how to fix it on a Windows server - we're running Windows server 2003 and experiencing this problem.
Try to address this issue by switching over to using a compound index that uses less file handles. Please find attached a patched jar file (bonnie-2006.03.30-patched.jar) and copy to your confluence/WEB-INF/lib directory and restart.
The newest release of Confluence 2.3 already includes this patch.
I have encountered the problem again, even with the bonnie-2006.03.30-patched.jar in place.
Hi Michael,
Could you please create a support issue for your request at http://support.atlassian.com I shall deal with it separately - there may be something else going on. Thanks, Already have - it's issue CSP-6493
Has been taken over by above CSP
We are using Confluence 2.2.8. When installing the patch jar file in WEB-INF/lib, should one delete the old bonnie.jar file?
Einar,
The correct answer is yes, remove the old one however, If your up for the upgrade, I'd suggest a move to 2.3.1 or better. Our 'too many open files' issue was never resolved with this patch, it only helped to prolong how often the Index was optimized and then when it did optimize it caused just as much latency. Eventually our server wouls still crash out with 'too many open files'. It was not until we moved to 2.3.1 that this issue went away. The compound indexing is 2.3.1 also really changed our server performance. Obviously every environment is different, I only speak of my experiences.
Hi Einar,
Let me please just clarify this matter. Up to the version of Confluence 2.3, Lucene java text search engine module was not using compound indexing and thus some users were experiencing problems with 'too many files opened'. Since this problem was resolved by applying the compound indexing, we have had no enquiries forwarded to us regarding problems with indexing. Let me know how you go and in case you need our support, please open a support ticket in http://support.atlassian.com Greg and Ivan,
Thank you both for your comments and clarifications. Very much appreciated. Ok, I have removed the old bonnie.jar file and rebuilt the index – will see how it works. Also planning on upgrading to 2.3.x in about a month, assuming that all our critical macros are compatable (currently some are not, like the calendar). Ivan – perhaps it's obvious to most everyone, but it may be an idea to mention that one should remove the old bonnie.jar file in the second bullet (bottom of page) here: http://confluence.atlassian.com/display/DOC/Fix+%27Too+many+open+files%27+error+on+Linux+by+increasing+filehandles?showComments=true#comments Thanks again, Einar I have attached a corrected version of the patched bonnie jar. This should be used with any 2.2.x instance to make Confluence reduce file handle usage by using a compound Lucene index.
What's changed from the previous version? I'd like to know how significant the change is to see if it's worth scheduling an outage for.
Has this change been reflected in the 2.2.3 build? Hi Michael,
If you are still experiencing out of file handles on an instance of Confluence 2.2.x using the original patched bonnie jar then this patch should resolve it and I would consider it worth scheduling an outage for. If you aren't having file handle issues anymore then I wouldn't bother at this stage. This patch is for an issue in Confluence 2.2.x that does not occur in Confluence 2.3 or higher, so this patch should not be used for 2.3.x instances (I assume that is what you meant) Cheers, I have an instance of Confluence 2.5.3 where this issue is happening.
I have also experienced this again with 2.5.3 while the index was being optimized.
It only happened once but figure it's worth noting. The log files looked very similar to the ones I had seen in the past with this issue. This issue has a regression in 2.5.x which was fixed in 2.5.7. See
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Resolved
Major
too many files open error due to bonnie.LuceneException
http://confluence.atlassian.com/x/Jd4C