[ https://issues.apache.org/jira/browse/LUCENE-4025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Shai Erera updated LUCENE-4025: ------------------------------- Attachment: LUCENE-4025.patch Patch adds maybeRefreshBlocking which blocks on refreshLock. It also: * Renames reopenLock to refreshLock * Shares the refresh logic between maybeRefresh and maybeRefreshBlocking. * Switches to use ReentrantLock instead of Semaphore(1): ** It allows to protectively obtain the lock in doMaybeRefresh (see comment in the code) ** It is better in general because it's equivalent to Semaphore(1), yet protects against an accidental bug where someone changes Semaphore(1) to Semaphore(>1). I'll add a CHANGES entry after the patch is reviewed and we agree on the approach. > ReferenceManager.maybeRefresh should allow the caller to block > -------------------------------------------------------------- > > Key: LUCENE-4025 > URL: https://issues.apache.org/jira/browse/LUCENE-4025 > Project: Lucene - Java > Issue Type: Improvement > Components: core/search > Reporter: Shai Erera > Priority: Minor > Fix For: 4.0 > > Attachments: LUCENE-4025.patch > > > ReferenceManager.maybeRefresh() returns a boolean today, specifying whether > the maybeRefresh logic was executed by the caller or not. If it's false, it > means that another thread is currently refreshing and the call returns > immediately. > I think that that's inconvenient to the caller. I.e., if you wanted to do > something like: > {code} > writer.commit(); > searcherManager.maybeRefresh(); > searcherManager.acquire(); > {code} > It'd be better if you could guarantee that when the maybeRefresh() call > returned, the follow on acquire() will return a refreshed IndexSearcher. Even > if you omit the commit instruction, it'd be good if you can guarantee that. > I don't quite see the benefit of having the caller thread not block if > there's another thread currently refreshing. In, I believe, most cases, you'd > anyway have just one thread calling maybeRefresh(). Even if not, the only > benefit of not blocking is if you have commit() followed by maybeRefresh() > logic done by some threads, while other threads acquire searchers - maybe > then you wouldn't care if another thread is currently doing the refresh? > Actually, I tend to think that not blocking is buggy? I mean, what if two > threads do commit() + maybeRefresh(). The first thread finishes commit, > enters maybeRefresh(), acquires the lock and reopens the Reader. Then the > second thread does its commit(), enters maybeRefresh, fails to obtain the > lock and exits. Its changes won't be exposed by SM until the next > maybeRefresh() is called. > So it looks to me like current logic may be buggy in that sense? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org