lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Wolanin <peter.wola...@acquia.com>
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
docs.

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

-Peter

On Mon, May 24, 2010 at 9:10 AM,  <karl.wright@nokia.com> 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.
peter.wolanin@acquia.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message