Improve names returned by server_info counters #4031
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
@scottschurr authored this commit and it has been running on reporting servers.
High Level Overview of Change
Historically, quite a number of different kinds of operations have been running in the
JobQueue
asjtCLIENT
. These include:Placing all of these operation types under
jtCLIENT
made them indistinguishable whenserver_info
returned usage of theJobQueue
. This commit improves visibility of the operations being performed in theJobQueue
by providing uniquejtClient*
priorities listed above.This change has the side effect of giving the different operations different priorities in the queue. I don't think this will have any negative impact on the ledger. And none has been observed in the reporting mode servers. But it's worth thinking about during the review. The priorities of the new job classifications are, from low to high priority:
These priorities can be trivially changed (by re-ordering their appearance in the
enum
) if any reviewer sees a good reason to do so.Context of Change
When debugging overloading of the
JobQueue
it was noted that many of the entries simply saidclientCommand
. We wanted to understand which jobs were actually running in theJobQueue
. Separating out the various jobs being handled under theclientCommand
umbrella was an easy way to accomplish the goal without adding to the pre-existing complexity.Type of Change
No unit tests were added for this change.