Thank you Hoss, this is exactly what I need! Currently I perform reindexing
once a month, and it takes few days... Very slow... Over 2 millions
documents (not too much; 300Mb in files), database & SOLR on a same box, and
SOLR uses about 60-80% CPU. I will implement real-time updates, via direct
Jav
: :you could even have the postCommit hook of your writer trigger a commit
: :call on your readers so they reopen the newly updated index.
:
: Thanks, I need "separate JVMs" so "writer triggers a commit call on readers"
: is slightly unclear... I want to use separate applications, webmodule with
:
:you could even have the postCommit hook of your writer trigger a commit
:call on your readers so they reopen the newly updated index.
Thanks, I need "separate JVMs" so "writer triggers a commit call on readers"
is slightly unclear... I want to use separate applications, webmodule with
reader, and
: - Can I use separate JVMs for same Directory object? One process will
: create/update/delete, and another search.
: - Can I use separate JEE contexts inside same JVM?
:
: Looks like "singleton" is a must, but separate "search" should be
: possible...
in theory it should work, Solr doens't do an
Additional questions regarding EmbeddedSolr (for using the Solr API directly
without HTTP):
- Can I use separate JVMs for same Directory object? One process will
create/update/delete, and another search.
- Can I use separate JEE contexts inside same JVM?
Looks like "singleton" is a must, but sep
Daniel Einspanjer wrote:
The example EmbeddedSolr class on the wiki makes use of getUpdateHandler
which was added after 1.1 (so it seems to be available only on trunk).
I'd really like to move to an embedded Solr sooner rather than later. My
questions are:
- Would it be easy/possible to work
