[
https://issues.apache.org/jira/browse/HTRACE-235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14737431#comment-14737431
]
Colin Patrick McCabe commented on HTRACE-235:
---------------------------------------------
Thanks, [~clehene]. Great work.
Configuration keys: is there a reason to use dashes in some places rather than
dots?
Transport: I would prefer to see something like a {{TransportBuilder}} rather
than a {{Transport#open}} method. If you have an open method then you need
mutable state for many things that actually will never change once the
transport is opened.
{{List<byte[]>}} seems like an odd choice. Why not {{ByteBuffer}} or
{{List<ByteBuffer>}}?
{code}
89 if (isOpen) producer.close();
90 else LOG.warn("Attempted to close already closed transport");
91 isOpen = false;
{code}
Please put braces around "if" statements.
What is the synchronization like for this class? Can we assume that it will
never be concurrently accessed by more than one thread? If not, we will need
synchronization or atomic variables for {{isOpen}}.
> 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.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)
