Thank you Erick,
Fortunately I can modify the data feeding process to start my post-indexing tasks. 2014-06-30 22:13 GMT+02:00 Erick Erickson <erickerick...@gmail.com>: > The paradigm is different. In SolrCloud when a client sends an indexing > request to any node in the system, when the response comes back all the > nodes (leaders, followers, etc) have _all_ received the update and > processed it. So you don't have to care in the same way. > > As far as different segments, versions, and all that this is entirely > expected. > Considering the above. Packet->leader. leader->follower. Each of them is > independently indexing the documents, there is no replication. So, since > the two servers started at different times, things like the autocommit > interval > can kick in at different times and the indexes diverge in terms of segment > counts, version numbers, whatever. They'll return the same _documents_, > but.... > > FWIW, > Erick > > On Mon, Jun 30, 2014 at 7:55 AM, Giovanni Bricconi > <giovanni.bricc...@banzai.it> wrote: > > Hello > > > > I have one application that queries solr; when the index version changes > > this application has to redo some tasks. > > > > Since I have more than one solr server, I would like to start these tasks > > when all solr nodes are synchronized. > > > > With master/slave configuration the application simply watched > > http://myhost:8080/solr/admin/cores?action=STATUS&core=0bis > > on each solr node and checked that the commit time msec was equal. When > the > > time changes and becomes equal on all the nodes the replication is > complete > > and it is safe to restart the tasks. > > > > Now I would like to switch to a solrcloud configuration, splitting the > core > > 0bis in 3 shards, with 2 replicas for each shard. > > > > After refeeding the collection I tried the same approach calling > > > > > http://myhost:8080/solr/admin/cores?action=STATUS&core=0bis_shard3_replica2 > > > > for each core of the collection, but with suprise I have found that on > the > > same stripe the version of the index, the number of segments and even the > > commit time msec was different!! > > > > I was thinking that it was possible to check some parameter on each > > stripe's core to check that everithing was up to date, but this does not > > seem to be true. > > > > Is it possible somehow to capture the "commit done on every core of the > > collection" event? > > > > Thank you > > > > Giovanni >
