Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@lucene.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=dk20050327; d=ix.netcom.com;
  b=MgrF4THtH2+zasCI9jx4M9XB3jWbJLDo0vLpOBLA7T/tP0A66G1CAeycYcwrf0vt;
  h=Received:Reply-To:From:To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:In-Reply-To:X-MimeOLE:Importance:X-ELNK-Trace:X-Originating-IP;
Reply-To: <rengels@ix.netcom.com>
From: "Robert Engels" <rengels@ix.netcom.com>
To: <java-dev@lucene.apache.org>
Subject: RE: Question about RemoteSearchable, RMI and queries in parallel
Date: Wed, 12 Apr 2006 22:19:56 -0500
Message-ID: <LMENLAOACIBLMOIILNNNOELCFMAA.rengels@ix.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
In-Reply-To: <c9952a990604122009k6488d73dq8dbb976324645e0e@mail.gmail.com>
Importance: Normal

If using RMI, you need to register multiple RemoteSearchable at different
addresses - one for each index you want to search.

Some simple client code will allow you to select the proper one.

This is the simplest solution (from what I understand of your problem -
although I admit I am still not completely understanding the dilemma).

The other solution would be to just create your own higher level RMI
interface where the methods took an 'index name', and the server could
multiplex from there.

-----Original Message-----
From: wenjie zheng [mailto:wenjie.zheng@gmail.com]
Sent: Wednesday, April 12, 2006 10:09 PM
To: java-dev@lucene.apache.org
Subject: Re: Question about RemoteSearchable, RMI and queries in
parallel


Thanks for your reply.
I think I didn't address the problem very clear. Let me rephrase it.

There is no such problem if everything is local, literaly we can new as many
IndexSearchers as we need.
However given the fact that there is only one RemoteSearchable instance
running on Server A, how can I run multiple queries on Server B  (different
indices) at the same time w/o affecting each other.

On 4/12/06, Robert Engels <rengels@ix.netcom.com> wrote:
>
> I think you may need a much more advanced design - with change detection,
> parallel query execution, and index modification.
>
> A lot of it depends on you semantics of a search - does it mean at the
> results are 'almost right' at a moment in time, or are pending index
> changes
> made first before any queries. How you define this will affect the
> architecture greatly.
>
>
> -----Original Message-----
> From: wenjie zheng [mailto:wenjie.zheng@gmail.com]
> Sent: Wednesday, April 12, 2006 8:45 PM
> To: java-dev@lucene.apache.org
> Subject: Question about RemoteSearchable, RMI and queries in parallel
>
>
> My question is a little bit long. Thanks for your patience.
>
> I am working on project which requires remote searching ability. So I use
> RMI and RemoteSearchable class. Here is the system structure:
> Server A has all the indices on it and the RemoteSearchable object running
> on it. Server B accepts queries and use ParallelMultiSearcher  and RMI to
> search the indices on Server A.
> There are many indices on Server A, based on query I received, I choose
> different index to search from .
>
> For example, if I the query is from X, we will search indexX; if the query
> is from Y, we will search indexY. In order to do that, I changed the
> Searchable interface a little bit by adding function load(String folder)
> and
> implement it in all the subclasses. What load() does is to close the
> underlining reader of the first index and open the reader for the second
> index.
>
> So here is the problem I bumped into. When there are more than one queries
> coming at the same time and I wanted to process them in parallel,  the
> load() function called by the second query may accidently close the the
> reader of the first index, while searching on the first index is not
> finished yet.
>
> So, do I have to queue the queries up and execute them one after the
> other?
> Or do I have other options?
>
> Thanks,
> Wenjie
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org