[
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
