It seems this information is merely an informative / debugging aide, yet
the wording suggests there is a problem. If I'm right on this, at a
minimum the wording should be improved. But removal... I don't know; it
was non-trivial to build this mechanism and the choice of enabling it on
basically a
I remember talking to Tim and Mark about these a bit ago, and I think I had
started to remove them in my patch to switch to the ZK Embedded Server.
On Tue, Oct 5, 2021 at 11:49 AM Timothy Potter wrote:
> I don't have an opinion on this and don't recall the details from 7+
> years ago but I suspe
I don't have an opinion on this and don't recall the details from 7+
years ago but I suspect Ram was hoping to warn devs when they were
using ZK inefficiently? I'd have to do some debugging / deeper
investigation to see if these reports are actually still useful for
the current test suite. On the s
I think the problem has been a mix of cases. For many, search is not the
sytem of record, so data loss is not great, but not the end of the world.
For others, the number of issues you could run into caused them to take
different approaches. If you can keep the ZooKeeper connection stable
enough, yo
Do typical setups (users) of SolrCloud not care about no data loss in the
cluster, or are clusters maintained stable enough that these issues do not
happen? I feel moving to a cloud infra drives more instability and suspect
these issues becoming more prevalent/problematic then.
Indeed Terms (LIR)
