[
https://issues.apache.org/jira/browse/LUCENE-4025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13265195#comment-13265195
]
Simon Willnauer commented on LUCENE-4025:
-----------------------------------------
my take on this is that if you really want this point in time semantics you are
describing you should use your own application locking on top. You can simply
use a read/write lock and acquire the write lock if you enter the "commit"
block which I assume you don't do too frequently. The other option is to simply
call maybeRefresh in an empty loop. The non-blocking fashion is a big asset
here IMO since you can't build a non-blocking app with blocking components but
you can do the other way around.
bq. Not blocking might be buggy, while blocking might affect your performance.
that is bogus IMO.
> 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
