[ https://issues.apache.org/jira/browse/LUCENE-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12638898#action_12638898 ]
Uwe Schindler commented on LUCENE-112: -------------------------------------- The idea is not bad. And I think other frameworks based on Lucene use a similar approach. I implemented something similar using an FilterIndexReader with TimerTasks (but more complicated). But this could be rewritten using FilterIndexReader very easy. > [PATCH] Add an IndexReader implementation that frees resources when idle and > refreshes itself when stale > -------------------------------------------------------------------------------------------------------- > > Key: LUCENE-112 > URL: https://issues.apache.org/jira/browse/LUCENE-112 > Project: Lucene - Java > Issue Type: Improvement > Components: Index > Affects Versions: CVS Nightly - Specify date in submission > Environment: Operating System: All > Platform: All > Reporter: Eric Isakson > Priority: Minor > Attachments: IdleTimeoutRefreshingIndexReader.html, > IdleTimeoutRefreshingIndexReader.java > > > Here is a little something I worked on this weekend that I wanted to > contribute > back as I think others might find it very useful. > I extended IndexReader and added support for configuring an idle timeout and > refresh interval. > It uses a monitoring thread to watch for the reader going idle. When the > reader > goes idle it is closed. When the index is read again it is re-opened. > It uses another thread to periodically check when the reader needs to be > refreshed due to a change to index. When the reader is stale, it closes the > reader and reopens the index. > It is acually delegating all the work to another IndexReader implementation > and > just handling the threading and synchronization. When it closes a reader, it > delegates the close to another thread that waits a bit (configurable how > long) > before actually closing the reader it was delegating to. This gives any > consumers of the original reader a chance to finish up their last action on > the > reader. > This implementation sacrifices a little bit of speed since there is a bit > more > synchroniztion to deal with and the delegation model puts extra calls on the > stack, but it should provide long running applications that have idle periods > or frequently changing indices from having to open and close readers all the > time or hold open unused resources. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]