[ https://issues.apache.org/jira/browse/SOLR-14581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17141299#comment-17141299 ]
David Smiley commented on SOLR-14581: ------------------------------------- Thanks for improving Solr's documentation! For reference, your patch is simply the following: bq. +TIP: Each node has its own auto commit timer which starts upon receipt of an update. While Solr promises eventual consistency, leaders will generally receive updates *before* replicas; it is therefore possible for replicas to lag behind somewhat. > TIP: If this is a tip then... well.... what is the advise you are offering? Perhaps "NOTE:" is better. (see `about-this-guide.adoc`) is better. > Each node has its own auto commit timer No, each *core* (replica) has one. Nodes can host many cores which act independently. I'd like to propose the following new language. I thought about your approach of including some rationale but I think it's way more important to point out the consequences than the causes. bq. +NOTE: Using auto soft commit or commitWithin requires the client app to embrace the realities of "eventual consistency". Solr will make documents searchable at _roughly_ the same time across NRT replicas of a collection but there are no hard guarantees. Consequently, in rare cases, it's possible for a document to show up in one search only for it not to appear in a subsequent search occurring immediately after when the second is routed to a different replica. Also, documents added in a particular order (even in the same batch) might become searchable out of order of submission when there is sharding. CC [~erickerickson] > Document the way auto commits work in SolrCloud > ----------------------------------------------- > > Key: SOLR-14581 > URL: https://issues.apache.org/jira/browse/SOLR-14581 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation, SolrCloud > Affects Versions: master (9.0) > Reporter: Bram Van Dam > Priority: Minor > Attachments: SOLR-14581.patch > > > The documentation is unclear about how auto commits actually work in > SolrCloud. A mailing list reply by Erick Erickson proved to be enlightening. > Erick's reply verbatim: > {quote}Each node has its own timer that starts when it receives an update. > So in your situation, 60 seconds after any give replica gets it’s first > update, all documents that have been received in the interval will > be committed. > But note several things: > 1> commits will tend to cluster for a given shard. By that I mean > they’ll tend to happen within a few milliseconds of each other > ‘cause it doesn’t take that long for an update to get from the > leader to all the followers. > 2> this is per replica. So if you host replicas from multiple collections > on some node, their commits have no relation to each other. And > say for some reason you transmit exactly one document that lands > on shard1. Further, say nodeA contains replicas for shard1 and shard2. > Only the replica for shard1 would commit. > 3> Solr promises eventual consistency. In this case, due to all the > timing variables it is not guaranteed that every replica of a single > shard has the same document available for search at any given time. > Say doc1 hits the leader at time T and a follower at time T+10ms. > Say doc2 hits the leader and gets indexed 5ms before the > commit is triggered, but for some reason it takes 15ms for it to get > to the follower. The leader will be able to search doc2, but the > follower won’t until 60 seconds later.{quote} > Perhaps the subject deserves a section of its own, but I'll attach a patch > which includes the gist of Erick's reply as a Tip in the "indexing in > SolrCloud"-section. -- This message was sent by Atlassian Jira (v8.3.4#803005) --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org