lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Wolanin <>
Subject Re: Solr updateRequestHandler and performance vs. atomicity
Date Mon, 24 May 2010 13:31:15 GMT
We us an autocommit with Solr and I've had this worry too - apparently
if you get a hard crash Solr will roll back the not-yet-committed

I don't think it's happened more than once in a year, but still possible.


On Mon, May 24, 2010 at 9:10 AM,  <> wrote:
> Hi all,
> It seems to me that the “commit” logic in the Solr updateRequestHandler (or
> wherever the logic is actually located) conflates two different semantics.
> One semantic is what you need to do to make the index process perform well.
> The other semantic is guaranteed atomicity of document reception by Solr.
> In particular, it would be nice to be able to post documents in such a way
> that you can guarantee that the document is permanently in Solr’s queue,
> safe in the event of a Solr restart, etc., even if the document has not yet
> been “committed”.
> This issue came up in the LCF talk that I gave, and I initially thought that
> separating the two kinds of events would necessarily be an LCF change, but
> the more I thought about it the more I realized that other Solr indexing
> clients may also benefit from such a separation.
> Does anyone agree?  Where should this logic properly live?
> Thanks,
> Karl

Peter M. Wolanin, Ph.D.
Momentum Specialist,  Acquia. Inc.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message