[
https://issues.apache.org/jira/browse/LUCENE-4025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13265132#comment-13265132
]
Shai Erera commented on LUCENE-4025:
------------------------------------
bq. I'm torn here...
I'm also torn here :).
bq. Always blocking seems dangerous because "simple" apps, that call
.maybeRefresh() from searching threads, will suddenly see all search threads
block when a reopen is happening
maybeRefresh says that you should call this *periodically*. I consider
SearcherManager kind of advanced API. Calling maybeRefresh() on every search is
like calling IndexReader.openIfChanged before every search. If we need to,
let's document the implications of the method.
Not blocking might be buggy, while blocking might affect your performance. I
think that the performance issue is really and edge case of stupidity, while
the former is a simple expectation. maybeRefresh documents that if it returns
false, it might be that the next acquire won't return the most up-to-date
IndexSearcher, but it doesn't give you any way to ensure that.
As for the extra API, can we start by unnecessarily complicating the API? It
looks to me that the API is clear with plenty of sample code and documentation
(Mike, you even wrote a couple of blog posts about it). It's just a matter of
semantics and if we tell people to call maybeRefresh periodically, then let's
help them by ensuring this call does something.
> 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
>
>
> 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
