NodeInfo response should use a collection rather than fields#54460
Merged
williamrandolph merged 13 commits intoelastic:masterfrom Apr 13, 2020
Merged
Conversation
This is a first cut at giving NodeInfo the ability to carry a flexible list of heterogeneous info responses. The trick is to be able to serialize and deserialize an arbitrary list of blocks of information. It is convenient to be able to deserialize into usable Java objects so that we can aggregate nodes stats for the cluster stats endpoint. In order to provide a little bit of clarity about which objects can and can't be used as info blocks, I've introduced a new interface called "ReportingService."
I tried a different serialization for NodeInfo that would allow writing flexible, arbitrary lists of node info blocks, but it seems too early in the process to commit to anything definite, so I've backed out the change. I have removed the hard-coded getters (e.g., getOs()) in favor of a flexible method that can return heterogeneous kinds of info blocks (e.g., getInfo(OsInfo.class)). Taking a class as an argument removes the need to cast in the client code.
Collaborator
|
Pinging @elastic/es-core-infra (:Core/Infra/Plugins) |
pugnascotia
reviewed
Mar 31, 2020
| return totalIndexingBuffer; | ||
| } | ||
|
|
||
| private void addInfoIfNonNull(Class<? extends ReportingService.Info> clazz, ReportingService.Info info) { |
Contributor
There was a problem hiding this comment.
Maybename it maybeAddInfo(...)? I'm unsure if that's an improvement.
pugnascotia
approved these changes
Mar 31, 2020
Contributor
pugnascotia
left a comment
There was a problem hiding this comment.
I'm not mad keen on using classes as a keys, but I'm struggling to think of an alternative, so LGTM.
Contributor
Author
|
The alternative I can think of is just returning a The strategy for heterogeneous containers that I've chosen here is discussed in Effective Java, 2nd Edition, item 29: "Consider typesafe heterogeneous containers". |
rjernst
approved these changes
Apr 7, 2020
Member
rjernst
left a comment
There was a problem hiding this comment.
This is a clever approach. I think it will make using the new response a lot easier extracting a typed info. The one caveat is it means we need to ensure each info type class is unique when registering services with infos, but that is for later. LGTM!
server/src/main/java/org/elasticsearch/action/admin/cluster/node/info/NodeInfo.java
Outdated
Show resolved
Hide resolved
Contributor
Author
|
@elasticmachine please run elasticsearch-ci/2 |
williamrandolph
added a commit
to williamrandolph/elasticsearch
that referenced
this pull request
Apr 13, 2020
…#54460) This is a first cut at giving NodeInfo the ability to carry a flexible list of heterogeneous info responses. The trick is to be able to serialize and deserialize an arbitrary list of blocks of information. It is convenient to be able to deserialize into usable Java objects so that we can aggregate nodes stats for the cluster stats endpoint. In order to provide a little bit of clarity about which objects can and can't be used as info blocks, I've introduced a new interface called "ReportingService." I have removed the hard-coded getters (e.g., getOs()) in favor of a flexible method that can return heterogeneous kinds of info blocks (e.g., getInfo(OsInfo.class)). Taking a class as an argument removes the need to cast in the client code.
williamrandolph
added a commit
that referenced
this pull request
Apr 13, 2020
…#55132) This is a first cut at giving NodeInfo the ability to carry a flexible list of heterogeneous info responses. The trick is to be able to serialize and deserialize an arbitrary list of blocks of information. It is convenient to be able to deserialize into usable Java objects so that we can aggregate nodes stats for the cluster stats endpoint. In order to provide a little bit of clarity about which objects can and can't be used as info blocks, I've introduced a new interface called "ReportingService." I have removed the hard-coded getters (e.g., getOs()) in favor of a flexible method that can return heterogeneous kinds of info blocks (e.g., getInfo(OsInfo.class)). Taking a class as an argument removes the need to cast in the client code.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
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.
When the nodes info endpoint is pluggable, the
NodeInfoobjects will need to be able to hold more than just a known group of heterogeneous objects representing different kinds of information. To this end, this PR introduces aReportingService.Infointerface, which each of the component info objects now inherits. The NodeInfo class can then replace its individual fields with a collection ofReportingService.Infoobjects. For this collection, I've chosen a map keyed on object type, which gives us the ability to handle casting dynamically in thegetInfo()method. I'm open to alternate approaches.I'm leaving the serialization of the
NodeInfoobject alone until I'm sure about how it should look in the long term. We don't want to get stuck supporting an intermediate serialization in future releases. (See #54305 for context.)Relates #52975