Add a configurable randomness source - #218
Merged
Merged
Conversation
willarmiros
reviewed
Sep 26, 2020
willarmiros
left a comment
willarmiros
left a comment
Contributor
There was a problem hiding this comment.
Thanks again for the changes! Left some thoughts and we should prob wait to hear from @anuraaga before getting this in.
rhernandez35
force-pushed
the
random
branch
from
September 28, 2020 22:45
2f49379 to
6bff2f8
Compare
anuraaga
reviewed
Sep 29, 2020
anuraaga
left a comment
anuraaga
left a comment
Contributor
There was a problem hiding this comment.
Sorry for the late review - left a high level comment about the internal API. Thanks a lot for the help @rhernandez35!
rhernandez35
force-pushed
the
random
branch
from
September 29, 2020 22:20
6bff2f8 to
c6f707b
Compare
Contributor
Author
|
OK, I moved the random generators to |
rhernandez35
force-pushed
the
random
branch
from
September 29, 2020 22:21
c6f707b to
0610913
Compare
anuraaga
reviewed
Sep 30, 2020
willarmiros
reviewed
Sep 30, 2020
willarmiros
left a comment
willarmiros
left a comment
Contributor
There was a problem hiding this comment.
Couple more comments
rhernandez35
force-pushed
the
random
branch
2 times, most recently
from
October 1, 2020 05:07
c1a2b50 to
66476ef
Compare
willarmiros
approved these changes
Oct 1, 2020
willarmiros
left a comment
willarmiros
left a comment
Contributor
There was a problem hiding this comment.
LGTM, will wait on @anuraaga to approve and merge. Thanks for your contribution and patience @rhernandez35!
rhernandez35
commented
Oct 1, 2020
I had two goals for this change: 1. Expose the configuration option without exposing any new classes or interfaces. We should be in strict control of possible randomness sources so we can guarantee that they actually do provide random values and that they provide randomness efficiently. I didn't want it to be possible for users to tank performance by inadvertently using a single `Random` instance. 2. Make the random source configurable and scoped to each `AWSXRayRecorder` instance. I didn't want to introduce any more global shared state, so this unfortunately meant I wasn't able to remove the global SecureRandom usage in two places: `TraceId#fromString` and `DefaultThrowableSerializationStrategy#describeInContext`. The latter is at least aware of the current entity and will try to use the ID generator from its creator when possible, but the former is unresolvable without adding more global shared state. This commit adds the following public APIs: * `AWSXRayRecorder#useFastIdGenerator` and `AWSXRayRecorder#useSecureIdGenerator`: for configuring the behavior of each `AWSXRayRecorder` instance. * `AWSXRayRecorderBuilder#useFastIdGenerator` and `AWSXRayRecorderBuilder#useSecureIdGenerator`: same as above * `AWSXRayRecorder#getIdGenerator`: for getting the configured ID generator * `ThrowableSerializationStrategy#describeInContext(Entity, Throwable, List<Subsegment>)`: a new method that allows the current entity to be provided to `ThrowableSerializationStrategy`. This is currently only useful for getting the ID generator from the current entity's creator, but I can imagine there being other uses for this later. There are also some classes under the `internal` package that are `public` by necessity. However, no class outside of `AWSXRayRecorder` has an API dependency on any of them and `AWSXRayRecorder` restricts which implementations can be used, so they're effectively hidden (or non-customizable, anyway). There are some other minor changes in this PR: * Removed quadratic String concatenation when generating Entity IDs * Removed quadratic StringBuilder char insertion when generating Trace IDs * `SegmentContextResolverChain` no longer double-resolves contexts
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
I had two goals for this change:
interfaces. We should be in strict control of possible randomness
sources so we can guarantee that they actually do provide random values
and that they provide randomness efficiently. I didn't want it to be
possible for users to tank performance by inadvertently using a single
Randominstance.AWSXRayRecorderinstance. I didn't want to introduce any more globalshared state, so this unfortunately meant I wasn't able to remove the
global SecureRandom usage in two places:
TraceId#fromStringandDefaultThrowableSerializationStrategy#describeInContext. The latter isat least aware of the local segment context and will try to use the
random generator from its creator when possible, but the former is
unresolvable without either adding more global shared state or exposing
the
RandomGeneratorclass.This commit adds the following public APIs:
AWSXRayRecorder#useFastRandomGeneratorandAWSXRayRecorder#useSecureRandomGenerator: for configuring the behaviorof each
AWSXRayRecorderinstance.AWSXRayRecorderBuilder#useFastRandomGeneratorandAWSXRayRecorderBuilder#useSecureRandomGenerator: same as aboveThrowableSerializationStrategy#describeInContext(SegmentContext, Throwable, List<Subsegment>): a new method that allows the currentsegment context to be provided to
ThrowableSerializationStrategy. Thisis currently only useful for getting the ID generator from the current
segment's creator, but I can imagine there being other uses for this
later.
I unfortunately had to add two internal-only public methods to
AWSXRayRecorderfor actually getting random values from its configuredrandom generator. Adding methods there allowed me to keep the
RandomGeneratorclass hidden from users.There are some other minor changes in this PR:
Entity#generateIdSegmentContextResolverChainno longer double-resolves contextsIssue #, if available:
#216
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.