Re: TLog for non-Solrcloud scenario

Thanks Erick, that summary is very helpful. Nawab On Mon, May 29, 2017 at 1:39 PM, Erick Erickson wrote: > Yeah, it's a bit confusing. I made Yonik and Mark take me through the > process in detail in order to write that blog, misunderstandings my > fault of course ;) > > bq: This makes me thi

Re: TLog for non-Solrcloud scenario

Yeah, it's a bit confusing. I made Yonik and Mark take me through the process in detail in order to write that blog, misunderstandings my fault of course ;) bq: This makes me think that at the time of soft-commit, the documents in preceding update requests are already flushed (might not be on the

Re: TLog for non-Solrcloud scenario

Thanks Erick, I have read different documents in this area and I am getting confused due to overloaded/"reused" terms. E.g., in that lucidworks page, the flow for an indexing request is explained as follows. This makes me think that at the time of soft-commit, the documents in preceding update re

Re: TLog for non-Solrcloud scenario

There's a long post here on this that might help: https://lucidworks.com/2013/08/23/understanding-transaction-logs-softcommit-and-commit-in-sorlcloud/ Short form: soft commit doesn't flush tlogs, does not start a new tlog, does not close segments, does not open new segments. Hard commit does all

TLog for non-Solrcloud scenario

Hi, SolrCloud document mentions: "The sync can be tunable e.g. flush vs fsync by default can protect against JVM crashes but not against power failure and can be much faster " Does it mean that flush protects against JVM crash but not power failu