[ 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