The ReplicationHandler class is not the most exemplar code to be looking at.
I found however the line that could be changed:
new Thread() {
@Override
public void run() {
doFetch(paramsCopy);
}
}.start();
rsp.add(STATUS, OK_STATUS);
It should be really simple to join on that thread depending on a rest
parameter.
I would change that code myself (which I did to my custom SOLR
installation) but I guess the fix should go for SOLR 4.x and not 3.x.
Sorry but I have no clue about how to contribute with code. Will check that
but if someone can point me to the right direction it would be nice.
Thanks
On Sat, Mar 29, 2014 at 9:49 AM, Mikhail Khludnev <
mkhlud...@griddynamics.com> wrote:
> Hello,
> We did this for our fork, if you are not happy with "RESTful polling", or
> think that the synchronous replication handler might be useful, please
> raise a jira.
> 27.03.2014 17:35 пользователь "Fermin Silva" <ferm...@olx.com> написал:
>
> > Hi,
> >
> > we are moving to native replication with SOLR 3.5.1.
> > Because we want to control the replication from another program (a cron
> > job), we decided to curl the slave to issue a fetchIndex command.
> >
> > The problem we have is that the curl returns immediately, while the
> > replication still goes in the background.
> > We need to know when the replication is done, and then resume the cron
> job.
> >
> > Is there a way to block on the replication call until it's done similar
> to
> > waitForSearcher=true when committing ?
> > If not, what other possibilities we have?
> >
> > Just in case, here is the solrconfig part in the slave (we pass masterUrl
> > in the curl url)
> >
> > <requestHandler name="/replication" class="solr.ReplicationHandler">
> > <lst name="slave">
> > <str name="masterUrl"></str>
> > </lst>
> > </requestHandler>
> >
> >
> > Many thanks in advance
> >
> > --
> > Fermin Silva
> >
>
--
Fermin Silva
Speed & Scalability Team
