[
https://issues.apache.org/jira/browse/SOLR-16793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17720706#comment-17720706
]
David Smiley commented on SOLR-16793:
-------------------------------------
For OVERSEERSTATUS, I'm looking at the [ref
guide|https://solr.apache.org/guide/solr/latest/deployment-guide/cluster-node-management.html#examples-using-overseerstatus]
for an example. I see the response has "overseer_queue" and presumably stats
below (not shown) under there. Maybe we should use this particular part of the
response for one of the queues only (collection work queue, I suggest), and add
another section for cluster state updates. WDYT?
> Overseer queue length metrics report the same value for all queues
> ------------------------------------------------------------------
>
> Key: SOLR-16793
> URL: https://issues.apache.org/jira/browse/SOLR-16793
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: metrics
> Affects Versions: 8.6
> Reporter: Paul McArthur
> Priority: Minor
>
> We observe that the reported queue length metrics for the Overseer's state
> update and collection work queues are always identical.
> I believe the cause is a shared instance of the Stats class that the Overseer
> injects into the ZkDistributedQueue instances for each of it's queues. The
> Stats class is only able to keep track of the length of one queue however,
> and this value would be clobbered whenever any of the ZkDistributedQueue
> instances updates it.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
