Skip to content

Conversation

rohitnair
Copy link
Contributor

We can figure out the right SegmentContextResolver at init time since it should remain static throughout the lifetime of an application (we're either running within Lambda or we're not - it should never change). Trying to resolve through the resolver chain at runtime seems unnecessary.

While typically it should not be very expensive to resolve both resolvers at runtime, I've noticed some performance overhead in environments where JSM (Java Security Manager) is enabled since the System.getenv() call that the LambdaSegmentContextResolver makes internally requires a permissions check (https://github.com/openjdk/jdk/blob/jdk-11%2B28/src/java.base/share/classes/java/lang/System.java#L991-L994)

Issue #, if available:
N/A

Description of changes:
See above

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

We can figure out the right SegmentContextResolver at init time since it should remain static throughout the lifetime of an application. Trying to resolve through the resolver chain each time at runtime seems unnecessary.
@rohitnair rohitnair requested a review from a team as a code owner July 14, 2023 01:00
@atshaw43
Copy link
Contributor

atshaw43 commented Jul 24, 2023

Thanks for the contribution.
I fixed the tests.
The Lambda environment variables were not set at the time the X-Ray Recorder was created so it defaulted to thread context.

@atshaw43 atshaw43 merged commit 398ec05 into aws:master Jul 24, 2023
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.

2 participants