Sorry to have dropped the ball on this past couple of days. I created the
JIRA with information shared on this mail thread.
https://issues.apache.org/jira/browse/SOLR-16838
Running further benchmarks reveals that the slowness is in
the searcher.getFirstMatch() call inside getInputDocument() .
*S
I have also gotten myself into situations where the leader election
looked broken and finding + restarting the overseer has always been
the best method to fix it. You can find this stuff by browsing
zookeeper.
On Mon, Jun 5, 2023 at 9:13 AM Walter Underwood wrote:
>
> I’ve seen this kind of thi
I’ve seen this kind of thing happen when the overseer is stuck for some reason.
Look for a long queue of work for the overseer in zookeeper. I’ve fixed that by
restarting the node which is the overseer. The new one wakes up and clears the
queue. I’ve only seen that twice.
Wunder
> On Jun 5, 20
Hi,
One possible reason for this could be that a shard leader experienced a high
load (or crash), causing its Zookeeper client timeout, e.g. losing its
live_nodes entry.
That would cause a leader election, and a replica would become the new leader.
Once the original leader re-joins it will no lon
