-
Notifications
You must be signed in to change notification settings - Fork 203
opentelemetry-http: Set context correctly for the server request body #3212
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
opentelemetry-http: Set context correctly for the server request body #3212
Conversation
...etalk-opentelemetry-http/src/main/java/io/servicetalk/opentelemetry/http/ScopeTrackerV2.java
Outdated
Show resolved
Hide resolved
74e7a87 to
05114f3
Compare
...etalk-opentelemetry-http/src/main/java/io/servicetalk/opentelemetry/http/ScopeTrackerV2.java
Outdated
Show resolved
Hide resolved
...etry-http/src/main/java/io/servicetalk/opentelemetry/http/OpenTelemetryHttpServerFilter.java
Outdated
Show resolved
Hide resolved
…pLifecycleObserver
…pLifecycleObserver
servicetalk-http-netty/src/main/java/io/servicetalk/http/netty/NettyHttpServer.java
Outdated
Show resolved
Hide resolved
|
Back to draft: I'm still seeing flakyness on the error pathways associated with the span completion happening before the |
| request.trailers().set("x-request-trailer", "request-trailer"); | ||
| request.payloadBody().writeAscii("bar"); | ||
| client.request(request).toFuture().get(); | ||
| Thread.sleep(SLEEP_DURATION); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What are those other events that may happen on server after response is received by the client? Is there any chance we can latch on some callback (onExchangeFinally or maybe on connection close) instead of using a sleep?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we either wait for a server to close (if that helps with races) or add a filter as the first one in the pipeline to track when it's time to start asserting attributes?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unfortunately, we need to give the traces time to materialize and I'm not sure a filter is going to help. In the agent there are methods to the tun of waitAndAssertTraces (here) which will give the traces some grace period to materialize but for whatever reason that doesn't seem to exist for the SDK testing tools.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mostly tried to understand what's delaying those events materialization. If it's because server-side request events may still happen after ServerContext is closed, it seems concerning and maybe we need to investigate separately why it happens. But if it's some buffering inside OTEL SDK or testing tools, then it's ok.
...-http/src/test/java/io/servicetalk/opentelemetry/http/OpenTelemetryHttpServerFilterTest.java
Outdated
Show resolved
Hide resolved
...-http/src/test/java/io/servicetalk/opentelemetry/http/OpenTelemetryHttpServerFilterTest.java
Outdated
Show resolved
Hide resolved
...-http/src/test/java/io/servicetalk/opentelemetry/http/OpenTelemetryHttpServerFilterTest.java
Outdated
Show resolved
Hide resolved
...-http/src/test/java/io/servicetalk/opentelemetry/http/OpenTelemetryHttpServerFilterTest.java
Outdated
Show resolved
Hide resolved
...-http/src/test/java/io/servicetalk/opentelemetry/http/OpenTelemetryHttpServerFilterTest.java
Outdated
Show resolved
Hide resolved
...emetry-http/src/main/java/io/servicetalk/opentelemetry/http/AbstractOpenTelemetryFilter.java
Outdated
Show resolved
Hide resolved
...etry-http/src/main/java/io/servicetalk/opentelemetry/http/OpenTelemetryHttpServerFilter.java
Outdated
Show resolved
Hide resolved
...emetry-http/src/main/java/io/servicetalk/opentelemetry/http/AbstractOpenTelemetryFilter.java
Outdated
Show resolved
Hide resolved
...emetry-http/src/main/java/io/servicetalk/opentelemetry/http/AbstractOpenTelemetryFilter.java
Outdated
Show resolved
Hide resolved
39d73d9 to
9d381a3
Compare
9d381a3 to
01f2ada
Compare
|
The build of 0d583df (disable offloading of the service call) demonstrates that if we remove offloading we have a stable build. However, this is not a realistic behavior for the majority of services, but refactoring the offloading behavior is something we should defer to another PR. |
idelpivnitskiy
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, only minor comments and questions about Thread.sleep:
...icetalk-opentelemetry-http/src/main/java/io/servicetalk/opentelemetry/http/ScopeTracker.java
Outdated
Show resolved
Hide resolved
| import static java.util.Objects.requireNonNull; | ||
|
|
||
| class ScopeTracker implements TerminalSignalConsumer { | ||
| final class ScopeTracker implements TerminalSignalConsumer { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Definitely not in this PR, but maybe later we can offer tracker as a public utility for other use-cases
| response.cancel(true); | ||
| }); | ||
| // For the HTTP/1.x server, we don't necessarily see the cancellation until we shutdown the server. | ||
| Thread.sleep(SLEEP_DURATION); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is sleep still required after ServerContext is closed?
| request.trailers().set("x-request-trailer", "request-trailer"); | ||
| request.payloadBody().writeAscii("bar"); | ||
| client.request(request).toFuture().get(); | ||
| Thread.sleep(SLEEP_DURATION); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we either wait for a server to close (if that helps with races) or add a filter as the first one in the pipeline to track when it's time to start asserting attributes?
...-http/src/test/java/io/servicetalk/opentelemetry/http/OpenTelemetryHttpServerFilterTest.java
Outdated
Show resolved
Hide resolved
...etry-http/src/main/java/io/servicetalk/opentelemetry/http/OpenTelemetryHttpServerFilter.java
Outdated
Show resolved
Hide resolved
|
@idelpivnitskiy, wrt |
Motivation:
We need to also consider the request body when tracking signals and setting context.
Modifications:
Properly track the response and account for the NettyHttpServer auto-drain behavior as well.