Shai Erera created LUCENE-4025:
----------------------------------
Summary: 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: [email protected]
For additional commands, e-mail: [email protected]
