Why do you only want to run it on the leader? This seems like a misunderstanding of how NRT replication works.
wunder Walter Underwood [email protected] http://observer.wunderwood.org/ (my blog) > On May 8, 2021, at 6:26 AM, Ilan Ginzburg <[email protected]> wrote: > > I'm not familiar with the way update processors work but an update is > processed by the leader after having been routed to it, right? > Would it be possible to run the leader specific code there/then while > taking advantage of knowing execution happens on the leader? > > Ilan > > Le ven. 7 mai 2021 à 21:20, lamine lamine <[email protected]> a > écrit : > >> Hi Solr people, >> I am writing a custom UpdateProcessor, part of a custom plugin, and need >> to run some code only on the shard leader. This is a plugin, so I cannot >> access the DistributedUpdateProcessor.isLeader() method which is not >> public. >> For now I am copying-pasting the below code, but I am thinking there's got >> to be a better way to do it. >> private boolean getIsLeader() { >> final boolean isZkAware = >> req.getCore().getCoreContainer().isZooKeeperAware(); >> if (!isZkAware) { >> return getNonZkLeaderAssumption(req); >> } >> String shardId = cloudDesc.getShardId(); >> try { >> Replica leaderReplica = >> zkController.getZkStateReader().getLeaderRetry(collection, shardId); >> return leaderReplica.getName().equals(cloudDesc.getCoreNodeName()); >> } >> catch (InterruptedException e) { >> throw new ZooKeeperException(SolrException.ErrorCode.SERVER_ERROR, >> “Error TODO", e); >> } >> } >> I think there is also another way to do it using cloudDesc.isLeader() but >> my understanding, if I am not wrong, is that the first code gives the most >> accurate state. Am I right? Is this the only way to get the most accurate >> state about the current leader? >> >> Also, should I run it every time I need to check the current status as the >> leader can change anytime? What's the impact in terms of performance? >> >> Thank you for your help in advance. >> Lamine >> >> >>
