Re: solrcloud "indexing completed" event

[Giovanni Bricconi <gi...@banzai.it>]

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 <er...@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
> <gi...@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
>