Re: solrcloud "indexing completed" event
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 : > 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 > 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 >
Re: solrcloud "indexing completed" event
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 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
solrcloud "indexing completed" event
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
