Skip to content

Conversation

mhl-b
Copy link
Contributor

@mhl-b mhl-b commented Sep 11, 2024

Add tracing handlers to HTTP stream. Also implement tracing handler for http-client-stats bytes counting and body logging. Added integ test for each.

@mhl-b mhl-b added >non-issue :Distributed Coordination/Network Http and internode communication implementations Team:Distributed (Obsolete) Meta label for distributed team (obsolete). Replaced by Distributed Indexing/Coordination. v9.0.0 labels Sep 11, 2024
@mhl-b mhl-b marked this pull request as ready for review September 11, 2024 21:27
@mhl-b mhl-b requested a review from Tim-Brooks September 11, 2024 21:27
@elasticsearchmachine
Copy link
Collaborator

Pinging @elastic/es-distributed (Team:Distributed)

@mhl-b mhl-b requested a review from DaveCTurner September 12, 2024 16:49
Copy link
Contributor

@Tim-Brooks Tim-Brooks left a comment

Choose a reason for hiding this comment

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

Looks like a fine design to me.

One note about releasing resources.

@Tim-Brooks
Copy link
Contributor

I opened a fix for the test compile issue: #112842

@mhl-b mhl-b requested a review from Tim-Brooks September 13, 2024 18:31
Copy link
Contributor

@Tim-Brooks Tim-Brooks left a comment

Choose a reason for hiding this comment

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

LGTM

@Override
public void close() {
try {
stream.close();
Copy link
Contributor

Choose a reason for hiding this comment

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

I think this will be called twice in normal operation? I think that is fine for those output streams. But you might check that is okay and mitigate with a closed field if necessary.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Currently stream will call close only on exceptional case, like channel close. So it should happen once. We might want to change behaviour for normal case to always close stream at the end and remove "isLast" parameter from handler.

Copy link
Contributor

Choose a reason for hiding this comment

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

I see that you made a change here, but from what I can tell the stream closes under non-exceptional circumstances too. (Which seems correct to me. It would be odd if it did not close.)

0 = {StackTraceElement@19194} "java.base/java.lang.Thread.getStackTrace(Thread.java:2417)"
1 = {StackTraceElement@19195} "org.elasticsearch.http.netty4.Netty4HttpRequestBodyStream.close(Netty4HttpRequestBodyStream.java:128)"
2 = {StackTraceElement@19196} "org.elasticsearch.http.netty4.Netty4HttpRequest.release(Netty4HttpRequest.java:118)"
3 = {StackTraceElement@19197} "org.elasticsearch.http.DefaultRestChannel.sendResponse(DefaultRestChannel.java:91)"
4 = {StackTraceElement@19198} "org.elasticsearch.rest.RestController$DelegatingRestChannel.sendResponse(RestController.java:889)"
5 = {StackTraceElement@19199} "org.elasticsearch.rest.RestController$MeteringRestChannelDecorator.sendResponse(RestController.java:906)"
6 = {StackTraceElement@19200} "org.elasticsearch.rest.RestController$DelegatingRestChannel.sendResponse(RestController.java:889)"
7 = {StackTraceElement@19201} "org.elasticsearch.rest.RestController$ResourceHandlingHttpChannel.sendResponse(RestController.java:954)"
8 = {StackTraceElement@19202} "org.elasticsearch.rest.action.RestChunkedToXContentListener.processResponse(RestChunkedToXContentListener.java:40)"
9 = {StackTraceElement@19203} "org.elasticsearch.rest.action.RestChunkedToXContentListener.processResponse(RestChunkedToXContentListener.java:25)"
10 = {StackTraceElement@19204} "org.elasticsearch.rest.action.RestActionListener.onResponse(RestActionListener.java:36)"
11 = {StackTraceElement@19205} "org.elasticsearch.action.bulk.IncrementalBulkService$Handler$2.onResponse(IncrementalBulkService.java:195)"
12 = {StackTraceElement@19206} "org.elasticsearch.action.bulk.IncrementalBulkService$Handler$2.onResponse(IncrementalBulkService.java:188)"
13 = {StackTraceElement@19207} "org.elasticsearch.action.ActionListenerImplementations$RunBeforeActionListener.onResponse(ActionListenerImplementations.java:335)"
14 = {StackTraceElement@19208} "org.elasticsearch.action.ActionListener$3.onResponse(ActionListener.java:399)"
15 = {StackTraceElement@19209} "org.elasticsearch.action.ActionListener$3.onResponse(ActionListener.java:399)"
16 = {StackTraceElement@19210} "org.elasticsearch.tasks.TaskManager$1.onResponse(TaskManager.java:202)"
17 = {StackTraceElement@19211} "org.elasticsearch.tasks.TaskManager$1.onResponse(TaskManager.java:196)"
18 = {StackTraceElement@19212} "org.elasticsearch.action.ActionListenerImplementations$RunBeforeActionListener.onResponse(ActionListenerImplementations.java:335)"
19 = {StackTraceElement@19213} "org.elasticsearch.action.ActionListener$3.onResponse(ActionListener.java:399)"
20 = {StackTraceElement@19214} "org.elasticsearch.action.ActionListenerImplementations$RunBeforeActionListener.onResponse(ActionListenerImplementations.java:335)"
21 = {StackTraceElement@19215} "org.elasticsearch.action.ActionListener$3.onResponse(ActionListener.java:399)"

Copy link
Contributor Author

Choose a reason for hiding this comment

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

right, completely forgot about Netty4HttpRequest.release

Copy link
Contributor Author

@mhl-b mhl-b Sep 14, 2024

Choose a reason for hiding this comment

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

And it's my doing, I implemented it for handling RestController exceptions that do not reach RestHandler. For example 400-bad-request. In that case need to close stream, while channel is still open.

@mhl-b mhl-b merged commit 76ba879 into elastic:partial-rest-requests Sep 14, 2024
12 of 15 checks passed
Tim-Brooks pushed a commit that referenced this pull request Sep 17, 2024
Tim-Brooks pushed a commit that referenced this pull request Sep 17, 2024
Tim-Brooks pushed a commit that referenced this pull request Sep 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

:Distributed Coordination/Network Http and internode communication implementations >non-issue Team:Distributed (Obsolete) Meta label for distributed team (obsolete). Replaced by Distributed Indexing/Coordination. v9.0.0

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants