: 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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
