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
