Update dependency io.zipkin.reporter2:zipkin-reporter-bom to v3.2.1 #6151
Conversation
|
obviates #6151 |
codefromthecrypt
force-pushed
the
new-sender
branch
from
fe4d370 to
8905680
Compare
codefromthecrypt
changed the title
codefromthecrypt
force-pushed
the
new-sender
branch
from
8905680 to
4334904
Compare
codefromthecrypt
force-pushed
the
new-sender
branch
2 times, most recently
from
6410932 to
f1c81a9
Compare
|
@jack-berg fyi I think the link fail is due to sonatype migrating to a central portal. The markdown may need to be adjusted as there's no direct replacement for that 404 https://central.sonatype.org/register/central-portal/#and-publishing-is-easy |
codefromthecrypt
force-pushed
the
new-sender
branch
from
f1c81a9 to
37e5303
Compare
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## main #6151 +/- ##
============================================
- Coverage 91.00% 90.99% -0.02%
Complexity 5646 5646
============================================
Files 619 619
Lines 16443 16438 -5
Branches 1663 1663
============================================
- Hits 14964 14957 -7
- Misses 1017 1018 +1
- Partials 462 463 +1 ☔ View full report in Codecov by Sentry. |
|
raised #6152 to fix markdown |
This migrates to the new `BytesMessageSender` base class used in zipkin-reporter. The old `Sender` is deprecated for removal. Notably, this only supports synchronous invocation now. If you need async, you'll have to use your own reporting loop or otherwise. Signed-off-by: Adrian Cole <[email protected]>
codefromthecrypt
force-pushed
the
new-sender
branch
from
37e5303 to
738da03
Compare
|
rebased |
| }); | ||
| return result; | ||
| try { | ||
| sender.send(encodedSpans); |
There was a problem hiding this comment.
I believe this changes the implementation from being non-blocking to blocking. In practice, this is fine because BatchSpanProcess / SImpleSpanProcessor never calls SpanExporter#export concurrently.
There was a problem hiding this comment.
yep it does make it explicitly blocking (depending on sender some would have sneakily blocked!) Thanks for the notes on impact
| */ | ||
| public ZipkinSpanExporterBuilder setSender(Sender sender) { | ||
| @Deprecated | ||
| public ZipkinSpanExporterBuilder setSender(zipkin2.reporter.Sender sender) { |
There was a problem hiding this comment.
The javadoc says that this will be removed in version 4. @open-telemetry/java-approvers we should figure out a plan with how we would like to handle this. If we bump to the next major version of zipkin, we wouldn't be able to support this API without a breaking change.
Might need to start publishing zipkin exporter artifacts which encode the major version of the zipkin dependency in the artifact name.
There was a problem hiding this comment.
FWIW I'm also not sure when we would do a version 4, but the point remains. The upgrade analysis forced this point, but I think critical thinking could make it easier.
Reporter 3.x isn't compatible with 2.x senders anyway. You haven't yet released the 3.x code yet.... one could argue you could remove this deprecated thing now and then not have to worry about v4.
There was a problem hiding this comment.
for context micrometer and spring boot are waiting for 1.35.0, and that's the first version that has any of the reporter 3 stuff. They will switch all the senders to the floor reporter version in 1.35.0 (which would be 3.2.1 when this lands). I know you have other concerns besides spring, but it is a data point that may help you decide.
There was a problem hiding this comment.
You haven't yet released the 3.x code yet.... one could argue you could remove this deprecated thing now and then not have to worry about v4.
Its a good point. We would have to do the same strategy I'm proposing - publish a new artifact id which includes zipkin 3 in the name some how. Deprecate, and eventually stop publishing the existing zipkin exporter artifact.
Added a topic to discuss in the tomorrow's java SIG.
There was a problem hiding this comment.
yep another choice for discussion is to shade it and just expose it as configuration instead of a library hook. anyway thanks for the help!
There was a problem hiding this comment.
@jack-berg do you have an idea which way you are going to go? If this doesn't merge it isn't dire, just I will need to help split micrometer's classpath as the only place this causes a conflict in is tests. I mean it will be a conflict in real life, too, but only for those simultaneously using otel and also direct zipkin stuff.
There was a problem hiding this comment.
I'm inclined to merge this PR and continue to publish the artifact under the coordinates. Then, we can consider publishing new artifact coordinates when zipkin publishes a v4 with the breaking change. Solving the problem now seems like putting the cart ahead of the horse.
@open-telemetry/java-approvers if there are no dissenting additional thoughts on this I'll plan on merging on 1/24/24.
There was a problem hiding this comment.
@jack-berg sounds good to me, and helps others from having more supporting work than maybe they can budget. v4 was just in the javadoc to tell people to stop using the old stuff as I noticed the senders were used outside of the reporters in that project. I made an issue about v4 and to not do that until it is important, likely with a new groupId/package openzipkin/zipkin-reporter-java#247
There was a problem hiding this comment.
I'm inclined to merge this PR and continue to publish the artifact under the coordinates. Then, we can consider publishing new artifact coordinates when zipkin publishes a v4 with the breaking change. Solving the problem now seems like putting the cart ahead of the horse.
👍
This migrates to the new
BytesMessageSenderbase class used in zipkin-reporter. The oldSenderis deprecated for removal.Notably, this only supports synchronous invocation now. If you need async, you'll have to use your own reporting loop or otherwise.