lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ken Krugler <kkrugler_li...@transpac.com>
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 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





Mime
View raw message