You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by David Smiley <ds...@apache.org> on 2021/02/17 22:20:16 UTC
ZkTestServer Watch limit violations
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
Re: ZkTestServer Watch limit violations
Posted by Mark Miller <ma...@gmail.com>.
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 at 10:23 AM Mark Miller <ma...@gmail.com> wrote:
> 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 <ds...@apache.org> 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 <md...@mdrob.com> 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 <th...@gmail.com>
>>> 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 <ds...@apache.org>
>>>> 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 <ds...@apache.org>
>>>> 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: dev-unsubscribe@solr.apache.org
>>>> For additional commands, e-mail: dev-help@solr.apache.org
>>>>
>>>> --
> - Mark
>
> http://about.me/markrmiller
>
--
- Mark
http://about.me/markrmiller
Re: ZkTestServer Watch limit violations
Posted by Mark Miller <ma...@gmail.com>.
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 <ds...@apache.org> 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 <md...@mdrob.com> 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 <th...@gmail.com>
>> 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 <ds...@apache.org> 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 <ds...@apache.org>
>>> 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: dev-unsubscribe@solr.apache.org
>>> For additional commands, e-mail: dev-help@solr.apache.org
>>>
>>> --
- Mark
http://about.me/markrmiller
Re: ZkTestServer Watch limit violations
Posted by David Smiley <ds...@apache.org>.
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 <md...@mdrob.com> 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 <th...@gmail.com>
> 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 <ds...@apache.org> 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 <ds...@apache.org>
>> 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: dev-unsubscribe@solr.apache.org
>> For additional commands, e-mail: dev-help@solr.apache.org
>>
>>
Re: ZkTestServer Watch limit violations
Posted by Mike Drob <md...@mdrob.com>.
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 <th...@gmail.com> 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 <ds...@apache.org> 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 <ds...@apache.org> 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: dev-unsubscribe@solr.apache.org
> For additional commands, e-mail: dev-help@solr.apache.org
>
>
Re: ZkTestServer Watch limit violations
Posted by Timothy Potter <th...@gmail.com>.
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 <ds...@apache.org> 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 <ds...@apache.org> 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: dev-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org
Fwd: ZkTestServer Watch limit violations
Posted by David Smiley <ds...@apache.org>.
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 <ds...@apache.org> 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
>