swarm/network: Keep span across roundtrip #19140
Merged
Conversation
This file contains 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
skylenet
approved these changes
Feb 20, 2019
zelig
approved these changes
Feb 20, 2019
kiku-jw
pushed a commit
to kiku-jw/go-ethereum
that referenced
this pull request
Mar 29, 2019
* swarm/newtork: WIP Span request span until delivery and put * swarm/storage: Introduce new trace across single fetcher lifespan * swarm/network: Put span ids for sendpriority in context value * swarm: Add global span store in tracing * swarm/tracing: Add context key constants * swarm/tracing: Add comments * swarm/storage: Remove redundant fix for filestore * swarm/tracing: Elaborate constants comments * swarm/network, swarm/storage, swarm:tracing: Minor cleanup
nonsense
referenced
this pull request
in ethersphere/swarm
May 8, 2019
* swarm/newtork: WIP Span request span until delivery and put * swarm/storage: Introduce new trace across single fetcher lifespan * swarm/network: Put span ids for sendpriority in context value * swarm: Add global span store in tracing * swarm/tracing: Add context key constants * swarm/tracing: Add comments * swarm/storage: Remove redundant fix for filestore * swarm/tracing: Elaborate constants comments * swarm/network, swarm/storage, swarm:tracing: Minor cleanup
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This PR addresses ethersphere/swarm#1209 (see copy of description below) which is an incremental part of ethersphere/swarm#1181
Until now, the spans are only valid within internal peer contexts, but we may want to trace durations from node makes request to node received delivery.
According to
opentracingsupport, if aSpanis to persist across asynchronous operations, it's the requester's responsibility to remember theSpanandFinish()it accordingly. In other words, aSpancannot be recalled after passing through thetracer.Inject()/tracer.Extract()serialization, only new spans (ChildOf(),FollowFrom()) can be created from theSpanContextthat's passed on.To this end, I've introduced a "store" for spans to be remembered. This "store" is a singleton per swarm instance. It seems to me to belong in the
swarm/tracingpackage, so I put it there.Unlike
LazyChunkReader.Read, we don't know how long a singleRetrieve Requesttook. We should update the spans to record the full duration of a retrieve request, until it is actually delivered on the requestor node.Good
Bad
