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

Store span warnings as tags in Cassandra #4313

Merged
merged 4 commits into from
Mar 19, 2023
Merged

Store span warnings as tags in Cassandra #4313

merged 4 commits into from
Mar 19, 2023

Conversation

utsavoza
Copy link
Contributor

@utsavoza utsavoza commented Mar 18, 2023

Which problem is this PR solving?

Short description of the changes

Signed-off-by: Utsav Oza <utsavoza96@gmail.com>
@utsavoza utsavoza requested a review from a team as a code owner March 18, 2023 03:14
@codecov
Copy link

codecov bot commented Mar 18, 2023

Codecov Report

Patch coverage: 100.00% and project coverage change: +0.01 🎉

Comparison is base (43c29a0) 97.09% compared to head (2c422d9) 97.10%.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #4313      +/-   ##
==========================================
+ Coverage   97.09%   97.10%   +0.01%     
==========================================
  Files         300      300              
  Lines       17668    17700      +32     
==========================================
+ Hits        17155    17188      +33     
+ Misses        413      412       -1     
  Partials      100      100              
Flag Coverage Δ
unittests 97.10% <100.00%> (+0.01%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
...n/storage/cassandra/spanstore/dbmodel/converter.go 100.00% <100.00%> (ø)

... and 1 file with indirect coverage changes

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

Copy link
Member

@yurishkuro yurishkuro left a comment

Choose a reason for hiding this comment

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

please add tests for error handling paths that are not covered (see codecov comments)

plugin/storage/cassandra/spanstore/dbmodel/converter.go Outdated Show resolved Hide resolved
Signed-off-by: Utsav Oza <utsavoza96@gmail.com>
kv, err := c.fromDBTag(&tags[i])
var retMe []model.KeyValue
for _, tag := range tags {
kv, err := c.fromDBTag(&tag)
Copy link
Member

Choose a reason for hiding this comment

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

please change it back. Original version has no copying and no memory allocations, yours has both. And pre-allocating array of known size is usually more efficient because it avoids re-allocation as the vector grows.

Copy link
Member

Choose a reason for hiding this comment

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

because your input and output lengths may not batch, you have to allocate with make(type, 0, len) and use append, not indexed assignment.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done

Signed-off-by: Utsav Oza <utsavoza96@gmail.com>
Signed-off-by: Utsav Oza <utsavoza96@gmail.com>
@yurishkuro
Copy link
Member

@utsavoza how/why do you think this fixes #704?

@utsavoza
Copy link
Contributor Author

utsavoza commented Mar 19, 2023

@yurishkuro I don't think this solves/fixes #704 unless we add Warnings as a separate field in the dbmodel's Span. I've updated the PR description to exclude the issue.

@yurishkuro
Copy link
Member

yurishkuro commented Mar 19, 2023

More I think about it, I think it does solve the issue. #704 doesn't actually explain the problem, it instead points to implementation details. I think the problem is that the spanHash used in the stored version is supposed to be different if anything about the span is different, including the warnings. This is how hash is calculated:

jaeger/model/span.go

Lines 63 to 68 in a631623

func (s *Span) Hash(w io.Writer) (err error) {
// gob is not the most efficient way, but it ensures we don't miss any fields.
// See BenchmarkSpanHash in span_test.go
enc := gob.NewEncoder(w)
return enc.Encode(s)
}

Since warnings previously were not part of the DB model, two identical domain spans that are only different in warnings would produce different hash code, even though when they are stored in the DB their stored image would be identical. I am not sure why even that would be a problem, sounds more like a theoretical issue that one would not come across in actual usage. But now that warnings are converted into special tags, the stored versions will be different, thus justifying the different hash codes, as was the intention. So feel free to keep the "resolves #704" in the description.

@yurishkuro yurishkuro merged commit b994aed into jaegertracing:main Mar 19, 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
2 participants