[
https://issues.apache.org/jira/browse/HTRACE-235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14936266#comment-14936266
]
Cosmin Lehene commented on HTRACE-235:
--------------------------------------
[~adriancole] Thanks, I didn't know about uglification.
That's using a different shade plugin, however
(https://github.com/immutables/maven-shade-plugin). I'm fine with it, but I
think it would be most effective if applied globally through plugin management.
[~colinmccabe] what do you think?
On a separate note, I wonder why haven't they (immutables) merged that into
the mainline.
> htrace-zipkin - add Kafka transport support
> --------------------------------------------
>
> Key: HTRACE-235
> URL: https://issues.apache.org/jira/browse/HTRACE-235
> Project: HTrace
> Issue Type: New Feature
> Reporter: Cosmin Lehene
> Assignee: Cosmin Lehene
> Fix For: 4.1
>
> Attachments: HTRACE-235.1.patch, HTRACE-235.2.patch,
> HTRACE-235.4.patch, HTRACE-235.patch
>
>
> Currently htrace-zipkin writes to the Scribe Thrift endpoint. However, Scribe
> is pretty much dead (although this is just Thrift interface so doesn't really
> need Scribe).
> A Kafka receiver would likely be useful not only for htrace-zipkin, so I
> think it could live outside. The htrace-native would be harder to get working
> with Kafka as there no supported Kafka native client (perhaps this could be
> experimented with https://github.com/edenhill/librdkafka).
> Writing to Kafka would also be possible by having a service that translates
> from Scribe Thrift to Kafka messages, however it would be nice to get the
> Kafka producer semantics on the client side (e.g. sync, async, batch size,
> etc.). This will come at the cost of having the Kafka producer as a
> dependency (larger jar), though as well as have a more complex receiver
> (multiple threads from the Kafka producer).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
