[WIP] Add headers parsing to ElasticsearchException#22675
Closed
tlrx wants to merge 3 commits intoelastic:masterfrom
Closed
[WIP] Add headers parsing to ElasticsearchException#22675tlrx wants to merge 3 commits intoelastic:masterfrom
tlrx wants to merge 3 commits intoelastic:masterfrom
Conversation
When rendered to XContent, ElasticsearchException's headers and other metadata are added to the XContent as new fields/objects.
For example, a `new CircuitBreakingException("Excessive stuff", 30L, 20L)` is rendered as the following JSON:
{
"type": "circuit_breaking_exception",
"reason": "Excessive stuff",
"bytes_wanted": 30,
"bytes_limit": 20
}
The same exception with an internal header "es.uuid"="foo" and a custom header "bar"="baz" would be rendered as:
{
"type": "circuit_breaking_exception",
"reason": "Excessive stuff",
"uuid": "foo"
"bytes_wanted": 30,
"bytes_limit": 20,
"header": {
"bar": "baz"
}
}
When this JSON is parsed back, there is no way to know if "bytes_wanted" is an internal header or a metadata because only custom headers (ie, which does not start with "es.") are added as sub fields of a parent "header" field. The internal headers are just added in the stream. In the best world, headers and metadata would have their own namespaces to avoid name conflicts but for now we can just assume that everything is a header.
This commit changes the ElasticsearchException so that:
- innerFromXContent() method is added and is in charge of parsing what is produced by innerToXContent()
- every field/object is considered as a header
- header objects/arrays names are flattened
- header values are converted to String (because headers only accept strings)
javanna
reviewed
Jan 19, 2017
| } | ||
| } else { | ||
| List<String> values = headers.getOrDefault(current, new ArrayList<>()); | ||
| values.add(String.valueOf(value)); |
Contributor
There was a problem hiding this comment.
after all, what would the parsed output of SearchPhaseExecutionException look like? I'm asking because that subclass prints out an array and potentially additional objects, I wonder how users would retrieve that additional info from the parsed ElasticsearchException.
Member
Author
There was a problem hiding this comment.
Additional objects are parsed as map, then the map keys are "flattened" and the map values converted to String, every field being added as a header. Then one can retrieve these info from headers with th right key name, there's a sample in the test testFromXContentWithExtraMetadataArrays()
Member
Author
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
2 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.
This is work in progress
When rendered to XContent, ElasticsearchException's headers and other metadata are added to the XContent as new fields/objects.
For example, a
new CircuitBreakingException("Excessive stuff", 30L, 20L)is rendered as the following JSON:The same exception with an internal header "es.uuid"="foo" and a custom header "bar"="baz" would be rendered as:
When this JSON is parsed back, there is no way to know if
bytes_wantedis an internal header or a metadata because only custom headers (ie, which does not start with "es.") are added as sub fields of a parentheaderfield. The internal headers are just added in the stream. In the best world, headers and metadata would have their own namespaces to avoid name conflicts but for now we can just assume that everything is a header.This commit changes the ElasticsearchException so that: