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

Update OTel snapshot to 723 for recordException #786

Merged
merged 15 commits into from
Jul 27, 2020

Conversation

anuraaga
Copy link
Contributor

This doesn't update to the latest snapshot which would have lots of conflicts with #785

@@ -287,6 +288,32 @@ class TracerTest extends AgentTestRunner {
}
}

def "capture exception()"() {
Copy link
Member

Choose a reason for hiding this comment

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

👍

@iNikem
Copy link
Contributor

iNikem commented Jul 25, 2020

Do you want also to fix all Tracers to use new API for exceptions?

@anuraaga
Copy link
Contributor Author

I'll do it in a separate PR I just want to get the baseline up on this one. There seems to be something wrong with async servlet which I'm digging

@iNikem
Copy link
Contributor

iNikem commented Jul 25, 2020

I have spent 1.5 days digging into async servlets :( Please wait for me to file a bug with my findings to not duplicate my efforts.

@iNikem
Copy link
Contributor

iNikem commented Jul 25, 2020

A, you have another issue. Mine is here: #787

@anuraaga
Copy link
Contributor Author

anuraaga commented Jul 26, 2020

@trask Would you be able to take a look at this branch? Having trouble getting servlet async tests passing. From what I can tell, previously the assertions weren't correct since they were effectively "0" || false always true. After fixing the tests, I noticed that TagSettingAsyncListener doesn't have access to the counting response if a user just calls startAsync so I am wrapping that too now to make sure the overridden response is used. But the count is still always 0, and with step debugging I noticed that even before the call to startAsync, it seems the original HttpServletResponse is already filled with a successful response, presumably before the counting. So stuck on why that could be happening

@trask
Copy link
Member

trask commented Jul 26, 2020

oh, you're right, that test validation was not correct, good find! i sent a PR to your branch anuraaga#2, i couldn't get rid of the it == 0 issue which seems to be needed to make the dispatch tests pass for now (i think it == 0 was the intention of that groovy ?: 0). maybe open an issue to fix the dispatch tests and remove the it == 0?

@anuraaga
Copy link
Contributor Author

Ok - yeah if nothing is obvious it's good to get this baseline update in and we'll debug more separately.

TRACER.end(span, response.getStatus());
}
}

public static void contentLengthHelper(Span span, ServletResponse response) {
if (response instanceof CountingHttpServletResponse) {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Notice JettyHandler didn't seem to have implemented counting, so thought it'd be a quick fix to add it, but some conflict between unnamed classloader and app classloader here :( Tomorrow will give another small look and then revert this and remove the assertion for now.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Found it was because I was missing this advice from the helper classes (was referring to servlet-3.0 while writing this). Filed #796 since this was confusing.

@anuraaga anuraaga merged commit 688733a into open-telemetry:master Jul 27, 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.

3 participants