lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ken Krugler <>
Subject "Special Circumstances" for embedded Solr
Date Fri, 21 May 2010 04:08:06 GMT
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, 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?


-- Ken

Ken Krugler
+1 530-210-6378
e l a s t i c   w e b   m i n i n g

View raw message