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 would be flawed because there can be many Solr instances per test, each can have watchers on the same znodes. It would also synchronize on a Watcher process call in the current impl, which you would very likely not want to do (don't think you should need to either given the thread safe counters used). My memory is though, it also does not end up decrementing counts as intended (maybe it did once, but long ago if so) and so really just ends up tracking the number of total watchers created for any given znode in aggregate from any object or solr instance. Watchers are recreated in most cases when they fire. So that information is not useless, but also not high value, and not a violation. - Mark On Tue, Oct 5, 2021 at 4:16 PM David Smiley <[email protected]> wrote: > 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 all SolrCloud tests suggests the authors (Tim) *really* felt it > was worth its weight, at least at the time. Maybe it should only dump this > info on a test failure? Shrug. > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley > > > On Tue, Oct 5, 2021 at 1:02 PM Mike Drob <[email protected]> wrote: > >> 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 <[email protected]> >> wrote: >> >>> 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 surface, it seems like everyone just >>> ignores them anyway (I certainly do) so maybe the noise in the test >>> suite outweighs their usefulness? >>> >>> On Mon, Oct 4, 2021 at 10:56 PM David Smiley <[email protected]> wrote: >>> > >>> > 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.CloudSolrClientTest#queryWithLocalShardsPreferenceRulesTest >>> > >>> > 10089 WARN (ZkTestServer Run Thread) [] o.a.s.c.ZkTestServer Watch >>> limit violations: >>> > Maximum concurrent create/delete watches above limit: >>> > >>> > 13 /solr/collections/localShardsTestColl/terms/shard2 >>> > 13 /solr/collections/localShardsTestColl/terms/shard1 >>> > 9 /solr/collections/localShardsTestColl/terms/shard3 >>> > 4 /solr/aliases.json >>> > 4 /solr/clusterprops.json >>> > 3 /solr/collections/localShardsTestColl/collectionprops.json >>> > 3 /solr/packages.json >>> > 3 /solr/security.json >>> > 3 /solr/configs/conf >>> > >>> > Maximum concurrent data watches above limit: >>> > >>> > 51 /solr/collections/localShardsTestColl/state.json >>> > >>> > Maximum concurrent children watches above limit: >>> > >>> > 23 /solr/collections/localShardsTestColl/state.json >>> > 16 /solr/live_nodes >>> > 8 /solr/collections >>> > 3 /solr/overseer/collection-queue-work >>> > >>> > ~ David Smiley >>> > Apache Lucene/Solr Search Developer >>> > http://www.linkedin.com/in/davidwsmiley >>> > >>> > >>> > On Wed, Feb 17, 2021 at 5:20 PM David Smiley <[email protected]> >>> wrote: >>> >> >>> >> I've noticed that it's quite common for a SolrCloud based test to >>> conclude with warnings about "Watch limit violations". I don't know how to >>> interpret these violations; it's normal to get them. Can someone offer >>> insights as to what this matter is about and what we ought to do about it? >>> >> >>> >> 63605 WARN (ZkTestServer Run Thread) [ ] o.a.s.c.ZkTestServer >>> Watch limit violations: >>> >> Maximum concurrent create/delete watches above limit: >>> >> >>> >> 4 /solr/aliases.json >>> >> 4 /solr/clusterprops.json >>> >> 3 /solr/packages.json >>> >> 3 /solr/security.json >>> >> 2 /solr/collections/ping_test/terms/shard2 >>> >> 2 /solr/collections/ping_test/terms/shard1 >>> >> 2 /solr/configs/conf >>> >> >>> >> ~ David Smiley >>> >> Apache Lucene/Solr Search Developer >>> >> http://www.linkedin.com/in/davidwsmiley >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> -- - Mark http://about.me/markrmiller
