Skip to content

SOLR-16458: Add node threads JAX-RS API - #4722

Open
Yashgoswami-ds wants to merge 2 commits into
apache:mainfrom
Yashgoswami-ds:SOLR-16458-node-threads-jaxrs
Open

SOLR-16458: Add node threads JAX-RS API#4722
Yashgoswami-ds wants to merge 2 commits into
apache:mainfrom
Yashgoswami-ds:SOLR-16458-node-threads-jaxrs

Conversation

@Yashgoswami-ds

Copy link
Copy Markdown
Contributor

Description

This PR adds a JAX-RS API for retrieving thread dump information from the receiving Solr node.

The existing ThreadDumpHandler functionality is exposed through the new JAX-RS endpoint while preserving the existing thread dump response structure and information.

Changes

  • Added the NodeThreadsApi endpoint for /node/threads.
  • Added the NodeThreadsResponse model for the JAX-RS response.
  • Updated ThreadDumpHandler to expose the JAX-RS API.
  • Added the required API and response model integration.
  • Preserved the existing thread count, deadlock, lock, synchronizer, monitor, CPU time, and stack trace information.

Testing

  • :solr:core:compileJava — passed
  • :solr:core:test --tests org.apache.solr.handler.admin.ThreadDumpHandlerTest — passed (4 tests, 2 skipped)

Issue

SOLR-16458

@JsonProperty("threadCount")
public Map<String, Object> threadCount;

@JsonProperty("deadlocks")

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i think, in a perfect, world, these Object would be more strongly typed, but I don't have a great sense of how complex that owuld be!

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree that strongly typed response fields would be preferable. I’ll look at the existing response models and update this to use appropriate typed classes where practical.

}

@Override
public Boolean registerV2() {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i am not totally positive, so need to look at other exampels, but maybe this registerV2 goes away, since this sithe v1 way? i thought the registerV2 was basically a way you could have a v1 api particpiate in the old v2 way... not posivite

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I’ll check the existing JAX-RS API implementations and verify whether registerV2() is still required here. I’ll update this accordingly.

@Yashgoswami-ds

Copy link
Copy Markdown
Contributor Author

@epugh
I’ve addressed the review comments:

  • Replaced the generic Map<String, Object> fields with strongly typed response models for thread count, thread information, locks, synchronizers, monitors, and stack traces.
  • Removed the obsolete registerV2() override since the endpoint is now exposed through the JAX-RS API.
  • Verified the changes with the relevant compilation and tests; the build passes successfully.

The updates are pushed in the latest commit.

@Yashgoswami-ds
Yashgoswami-ds requested a review from epugh August 10, 2026 21:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants