lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shai Erera (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (LUCENE-4025) ReferenceManager.maybeRefresh should allow the caller to block
Date Tue, 01 May 2012 05:25:44 GMT

    [ https://issues.apache.org/jira/browse/LUCENE-4025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13265663#comment-13265663
] 

Shai Erera commented on LUCENE-4025:
------------------------------------

Calling maybeRefresh in an empty loop is not good. You'd want to at least add some sleep in
between calls. And then you need to decide on the sleep interval. Complicate things.

What's not clear to me is why was this API made non-blocking in the first place? Did someone
complain about it being blocking?

bq. 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.

That's generally a correct statement, but who said that in the context of a ReferenceManager
you want to build a non-blocking app?

Perhaps a maybeRefreshBlocking() will be the best compromise after all. That method won't
return anything and will just block on reopenLock. I'll create a patch, let's see how it looks
first. While I'm at it, I'll rename reopenLock to refreshLock (reopenLock was from the time
it was in SearcherManager).
                
> 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message