-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Switch Thrift with Jaeger's fork #3050
Merged
yurishkuro
merged 4 commits into
jaegertracing:master
from
jpkrohling:jpkrohling/patched-thrift
Jun 3, 2021
Merged
Changes from all commits
Commits
Show all changes
4 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
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
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -43,7 +43,7 @@ require ( | |
github.com/opentracing-contrib/go-stdlib v0.0.0-20190519235532-cf7a6c988dc9 | ||
github.com/opentracing/opentracing-go v1.2.0 | ||
github.com/prometheus/client_golang v1.5.1 | ||
github.com/prometheus/common v0.10.0 // indirect | ||
github.com/prometheus/common v0.10.0 | ||
github.com/prometheus/procfs v0.1.3 // indirect | ||
github.com/rs/cors v1.7.0 | ||
github.com/securego/gosec v0.0.0-20200203094520-d13bb6d2420c | ||
|
@@ -73,4 +73,5 @@ require ( | |
honnef.co/go/tools v0.2.0 | ||
) | ||
|
||
replace github.com/gogo/protobuf => github.com/gogo/protobuf v1.3.2 | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The protobuf dependency has been removed, as the one used in the main section is the same. |
||
// TODO: remove once the 0.14.2 or 0.15.0 is released | ||
replace github.com/apache/thrift => github.com/jaegertracing/thrift v0.14.1-patch1 | ||
jpkrohling marked this conversation as resolved.
Show resolved
Hide resolved
|
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
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This change was interesting, as the new error is this:
Unable to process request body: size exceeded max allowed: 1869881447
. This seems to indicate that the fix is being picked up, but it did raise a warning in my head: are we really allocating more than 1GiB for this? Apparently, no. I usedruntime.MemStats
to measure the memory consumption before and after the HTTP call, and the usage was minimal (2 Alloc vs. 3 Alloc).There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is indeed interesting.
The old error message "Unknown data type" comes from
Skip
function, which is called when either the field id is not defined in the struct, or when the type of the field id doesn't match what's defined in the struct.The new error message "size exceeded max allowed" comes from size sanity checks, which could be called by a lot of
TProtocol
functions (for example,ReadString
,ReadBinary
,ReadMapBegin
,ReadListBegin
,ReadSetBegin
). This means the new code actually passed the field type check and is no longer skipped (or maybe previously the first field happened to match and it's the second field failed the field type check and caused the error, while in the new code the first field passed field type check but failed the size sanity check).runtime.MemStats
might be misleading. I believe it's the same as benchmark tests'ReportAllocs
, and this benchmark test reported 0 allocs/0 bytes which is certainly a lie (I have to use a much smaller size because the original one is too slow):There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@fishy, do you think this change raises flags? I wouldn't expect the payload for this test to cause such a huge message.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not necessarily.
If you dig into the code on what this does, the first ever read from the thrift payload is to
ReadListBegin
, which is one of the functions that would trigger the new error.Let's first convert the payload (
[]byte("not good")
) into raw bytes:[6e 6f 74 20 67 6f 6f 64]
.In
ReadListBegin
implementation, first it reads a byte,6e
, then it tries to read an int32 as the size of the list. For the reading of the int32, it reads the next 4 bytes (6f 74 20 67
), decode with bigendian, which results in 1869881447.So this is totally expected behavior.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And following
ReadListBegin
, jaeger's code didn't really do the pre-allocation. it just append spans to the slice and rely onappend
to do the allocation and grow the slice.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
y'all even already have a comment on that :)
jaeger/model/converter/thrift/zipkin/deserialize.go
Lines 51 to 52 in ff32436