Skip to content
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

Instrument Netty addTask to ensure complete coverage of async Runnables #1348

Merged
merged 4 commits into from
Oct 9, 2020
Merged

Conversation

johnbley
Copy link
Member

@johnbley johnbley commented Oct 8, 2020

We found that certain code paths in RxNetty through vanilla Netty exposed an issue where Netty WriteTasks weren't capturing the correct/any context during submission. Turns out that newer 4.1 variants of Netty have a backchannel "lazy" execution that uses execute(Runnable, boolean), bypassing the standard execute(Runnable). Fortunately, all the variants flow through to addTask(Runnable).

Without the addTask instrumentation addition, the added unit test fails with 3 traces (the second client request shows up under a brand new 3rd trace without any inherited context).

Newer versions of Netty introduce variants like execute(Runnable, boolean) which
aren't covered by the core execute(Runnable) instrumentation.  Fortunately they all
flow through to addTask(Runnable), which allows us to carry the context through properly.
@johnbley johnbley changed the title [WIP] Instrument Netty addTask to ensure complete coverage of async Runnables Instrument Netty addTask to ensure complete coverage of async Runnables Oct 8, 2020
@johnbley johnbley marked this pull request as ready for review October 8, 2020 19:55
@@ -27,7 +27,7 @@ muzzle {
}

dependencies {
library group: 'io.netty', name: 'netty-codec-http', version: '4.1.0.Final'
library group: 'io.netty', name: 'netty-codec-http', version: '4.1.52.Final'
Copy link
Contributor

Choose a reason for hiding this comment

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

Wouldn't it be enough to have later versions in latestDepTest? I think we still want to test with the oldest supported version.

Copy link
Member Author

Choose a reason for hiding this comment

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

Yep, thanks for that. Confirmed that with -PtestLatestDeps=true and the addTask instrumentation commented out the test fails, so reverting the gradle file.

Copy link
Member

@trask trask left a comment

Choose a reason for hiding this comment

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

looks good, thanks 👍

agree with @iNikem's comment about test version

@anuraaga
Copy link
Contributor

anuraaga commented Oct 9, 2020

For reference, we have this pattern if you need to be able to branch in the test based on whether it's normal or latest dep

systemProperty "testLatestDeps", testLatestDeps

Copy link
Member

@trask trask left a comment

Choose a reason for hiding this comment

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

Thanks, nice find!

@trask trask merged commit b34fd49 into open-telemetry:master Oct 9, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants