lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shai Erera" <ser...@gmail.com>
Subject Re: [jira] Commented: (LUCENE-1026) Provide a simple way to concurrently access a Lucene index from multiple threads
Date Thu, 29 Nov 2007 13:46:45 GMT
Part of the changes I've done is to have close() not throw exception when it
is being called twice (I don't think it's bad to call it twice). Maybe you
didn't copy that part of the code?
Because the tests run on my machine ...

I agree on the last statement. I just didn't want to introduce too many
changes at once. But having factory.close() close the MultiSearchAccessor as
well is good. If you change that, then the MultiSearcher test can be changed
as well to not call close().

You are right about the comment on MultiIndexAccessor's close implementation
(not closing its IndexAccessor instances). I must say that its functionality
is not very clear, because of lack of documentation (that's why I didn't
complete the documentation for this class). Can you update the javadocs
while you're changing that?

Thanks,

Shai.


On Nov 29, 2007 3:25 PM, Mark Miller (JIRA) <jira@apache.org> wrote:

>
>    [
> https://issues.apache.org/jira/browse/LUCENE-1026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12546719]
>
> Mark Miller commented on LUCENE-1026:
> -------------------------------------
>
> Quick comment:
>
> You have the MultiSearcher closing its own IndexAccessor's now. Maybe I
> messed up copying in your changes, but this causes an Exception in the tests
> as the IndexFactory also closes all of the IndexAccessor's. (Really, it owns
> them)
>
> It's probably a good idea for the MultiSearcher to have a close (clearing
> the two caches is not a bad idea), but I don't think the MultiSearcher
> should close IndexAccessors. It does not own those Accessors and other
> threads may be using them from the Factory. They are only kept around in the
> MultiSearcher so that it can release them later, back to the Factory.
>
> Also, probably the Factory.close method should call the MultiSearcher
> close rather than having to get the MuliSearcher and call close separately?
>
> Thoughts?
>
> - Mark
>
> > Provide a simple way to concurrently access a Lucene index from multiple
> threads
> >
> --------------------------------------------------------------------------------
> >
> >                 Key: LUCENE-1026
> >                 URL: https://issues.apache.org/jira/browse/LUCENE-1026
> >             Project: Lucene - Java
> >          Issue Type: New Feature
> >          Components: Index, Search
> >            Reporter: Mark Miller
> >            Priority: Minor
> >         Attachments: DefaultIndexAccessor.java,
> DefaultMultiIndexAccessor.java, IndexAccessor.java,
> IndexAccessorFactory.java, MultiIndexAccessor.java,
> shai-IndexAccessor-2.zip, shai-IndexAccessor.zip, shai-IndexAccessor3.zip,
> SimpleSearchServer.java, StopWatch.java, TestIndexAccessor.java
> >
> >
> > For building interactive indexes accessed through a network/internet
> (multiple threads).
> > This builds upon the LuceneIndexAccessor patch. That patch was not very
> newbie friendly and did not properly handle MultiSearchers (or at the least
> made it easy to get into trouble).
> > This patch simplifies things and provides out of the box support for
> sharing the IndexAccessors across threads. There is also a simple test class
> and example SearchServer to get you started.
> > Future revisions will be zipped.
> > Works pretty solid as is, but could use the ability to warm new
> Searchers.
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>


-- 
Regards,

Shai Erera

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message