Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Date: Thu, 6 May 2010 12:12:19 -0700 (PDT)
From: Chris Hostetter <hossman_lucene@fucit.org>
To: dev@lucene.apache.org
Subject: Re: Solr on AppEngine - patches? & a question
In-Reply-To: <o2w952e01251005032245r79d6bfd6zbe08ece212c821c0@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1005061204420.6092@radix.cryptio.net>
References: <o2w952e01251005032245r79d6bfd6zbe08ece212c821c0@mail.gmail.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


: Is there any interest in patches to make these classes extensible enough for
: use in this scenario?

I think it would definitely be informative for a lot of people if you 
would be willing/interested in posting your patches -- even if we 
can't/don't commit them for some reason, they can still serve as 
informative starting points for other people, and they might help us spot 
ways the code can be refactored/generalized to make your situation easier.

: Secondly, AppEngine also doesn't allow the creation of threads. This was
: mostly easy to work around (I created a ExecutorService using the current
: thread), except for the CountDownLatch locking stuff in the SolrCore
: constructor:
	...
: I don't completely understand what's going on here. My understanding is that
: it's locking the search executor so that it won't run until all the
: searchers are correctly initialized, and I'm guessing that SolrCore handles
: the case where simultaneous requests to the filter come in
: before initialization is complete somehow.

not exactly -- external requests won't be sent to the core until the 
constructor has finished, but "firstSearcher" queries configured in the 
solrconfig.xml are executed internally, and those need to be blocked 
untill all the components have been initialized.

: Since I'm running single threaded here, I've worked around that by
: commenting it out. Is that sufficient or is there a better way?

I'm not sure ... presumable your "ExecutorService using the current 
thread" approach wouldn't work here since it would defeat the point of 
blocking (but it would be no worse then commenting out -- that's one 
generalization we might support, a way to configure the ExecutorService 
used).  

I have no idea if there would be a better way of dealing with that.


-Hoss


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