Hi all,
We'd started using embedded Solr back in 2007, via a patched version
of the in-progress 1.3 code base.
I recently was reading http://wiki.apache.org/solr/EmbeddedSolr, and
wondered about the paragraph that said:
The simplest, safest, way to use Solr is via Solr's standard HTTP
interfaces. Embedding Solr is less flexible, harder to support, not
as well tested, and should be reserved for special circumstances.
Given the current state of SolrJ, and the expected roadmap for Solr in
general, what would be some guidelines for "special circumstances"
that warrant the use of SolrJ?
I know what ours were back in 2007 - namely:
- we had multiple indexes, but didn't want to run multiple webapps
(now handled by multi-core)
- we needed efficient generation of updated indexes, without
generating lots of HTTP traffic (now handled by DIH, maybe with
specific extensions?)
- we wanted tighter coupling of the front-end API with the back-end
Solr search system, since this was an integrated system in the hands
of customers - no "just restart the webapp container" option if
anything got wedged (might still be an issue?)
Any other commonly compelling reasons to use SolrJ?
Thanks,
-- Ken
--------------------------------------------
Ken Krugler
+1 530-210-6378
http://bixolabs.com
e l a s t i c w e b m i n i n g
