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: domain of nick.lothian@gmail.com
 designates 209.85.223.189 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:date:message-id:subject:from:to:content-type;
        b=JXu7iTMnU5O02XbE4I1woD9zqpur29qI6oTYr7denztUf1nQxaF7TZpP8Oxsc2Nrpy
         PpGhnjRf2I8zgHcZGXkCdajtEmwosLmSQ6X5PGE1PsAxtDXDMLiWdi+AtweTNjBRI0x0
         h5zkgRrlN1o+16mgDMY6eNpDYVnDr0bbv6xd4=
MIME-Version: 1.0
Date: Tue, 4 May 2010 15:15:29 +0930
Message-ID: <o2w952e01251005032245r79d6bfd6zbe08ece212c821c0@mail.gmail.com>
Subject: Solr on AppEngine - patches? & a question
From: Nick Lothian <nick.lothian@gmail.com>
To: dev@lucene.apache.org
Content-Type: multipart/alternative; boundary=0016e64ca94ea032e60485be3739

--0016e64ca94ea032e60485be3739
Content-Type: text/plain; charset=ISO-8859-1

I've got Solr working on Google AppEngine (mostly, anyway - it's read only
ATM, and I haven't done any stability testing).

For those of you who aren't aware, AppEngine doesn't allow file access,
while Solr is fairly dependent on file system access for configuration
files.

Solr allowed me to work around the majority of the file system dependencies
(by implementing a custom ResourceLoader etc), but I needed to alter
SolrCore.java, SolrResourceLoader.java and SolrDispatchFilter.java

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

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:

      searcherExecutor.submit(new Callable() {
        public Object call() throws Exception {
          latch.await();
          return null;
        }
      });

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.

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?

Nick

--0016e64ca94ea032e60485be3739
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div>I&#39;ve got Solr working on Google AppEngine (mostly, anyway - it&#39=
;s read only ATM, and I haven&#39;t done any stability testing).</div><div>=
<br></div><div>For those of you who aren&#39;t aware, AppEngine doesn&#39;t=
 allow file access, while Solr is fairly dependent on file system access fo=
r configuration files.</div>
<div><br></div><div>Solr allowed me to work around the majority of the file=
 system dependencies (by implementing a custom ResourceLoader etc), but I n=
eeded to alter SolrCore.java, SolrResourceLoader.java and SolrDispatchFilte=
r.java</div>
<div><br></div><div>Is there any interest in patches to make these classes =
extensible enough for use in this scenario?</div><div><br></div><div>Second=
ly, AppEngine also doesn&#39;t allow the creation of threads. This was most=
ly easy to work around (I created a ExecutorService using the current threa=
d), except for the CountDownLatch locking stuff in the SolrCore constructor=
:</div>
<div><br></div><div><div>=A0=A0 =A0 =A0searcherExecutor.submit(new Callable=
() {</div><div>=A0=A0 =A0 =A0 =A0public Object call() throws Exception {</d=
iv><div>=A0=A0 =A0 =A0 =A0 =A0latch.await();</div><div>=A0=A0 =A0 =A0 =A0 =
=A0return null;</div><div>=A0=A0 =A0 =A0 =A0}</div>
<div>=A0=A0 =A0 =A0});</div></div><div><br></div><div>I don&#39;t completel=
y understand what&#39;s going on here. My understanding is that it&#39;s lo=
cking the search executor so that it won&#39;t run until all the searchers =
are correctly=A0initialized, and I&#39;m guessing that SolrCore handles the=
 case where=A0simultaneous=A0requests to the filter come in before=A0initia=
lization=A0is=A0complete=A0somehow.=A0</div>
<div><br></div><div>Since I&#39;m running single threaded here,=A0I&#39;ve =
worked around that by commenting it out. Is that sufficient or is there a b=
etter way?</div><div><br></div><div>Nick</div>

--0016e64ca94ea032e60485be3739--