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 > > >
