Oh yeah, you will also have clients, such as the cloud client from the test
mini cluster also legitetmatly creating parallel watches on the same znodes
as Solr instance. Point being, even if it decremented, it would still be
reporting violations that did not make sense.
- Mark
On Wed, Oct 6, 2021
Yes, as far as I recall, it does not do what it says. The doc and volation
wording would suggest that it is checking if you make unnessary watchers
because one already exists at that time for a particular znode. You have
more that one watcher watching a znode in parallel at the same time.
This wou
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
Maybe Tim you may have an opinion on this one as you introduced this watch
limit violation checker in https://issues.apache.org/jira/browse/SOLR-6370 ?
Running just about any SolrCloud based test will cause this to dump some
info at the end. Even simple ones like
org.apache.solr.client.solrj.impl.
