NodeInfo response should use a collection rather than fields #54460
Conversation
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
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.
williamrandolph
added
>non-issue
:Core/Infra/Plugins
|
Pinging @elastic/es-core-infra (:Core/Infra/Plugins) |
pugnascotia
reviewed
Mar 31, 2020
| } | ||
|
|
||
| @Nullable | ||
| public ByteSizeValue getTotalIndexingBuffer() { | ||
| return totalIndexingBuffer; | ||
| } | ||
|
|
||
| private void addInfoIfNonNull(Class<? extends ReportingService.Info> clazz, ReportingService.Info info) { |
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
|
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
server/src/main/java/org/elasticsearch/action/admin/cluster/node/info/NodeInfo.java
Outdated
Show resolved
Hide resolved
|
@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.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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