[
https://issues.apache.org/jira/browse/HTRACE-235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14909001#comment-14909001
]
Cosmin Lehene commented on HTRACE-235:
--------------------------------------
bq. Configuration keys: is there a reason to use dashes in some places rather
than dots?
Only the old configuration keys contain dashes, the new ones have dots.
We'll warn with a deprecation message when used and can remove them in a future
version.
bq. 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.
I'm not completely sure I follow.
We need to pass the configuration object to the transport.
I avoided passing it through constructor as I kept Transport as an interface as
I didn't want to have an abstract class (less and simpler code).
This is why the configuration gets passed through open.
Are you suggesting using a builder to pass the configuration once the object is
constructed?
If so I'm not sure how would that be different than passing it in the
constructor directly.
bq. List<byte[]> seems like an odd choice. Why not ByteBuffer or
List<ByteBuffer>?
When we drain the queue we get a list of spans, hence the {{List}}
The zipkin span write operation will get the data in a
{{ByteArrayOutputStream}}. {{toByteArray}} will return a byte array, hence
{{List<byte[]>}}
Would there be any benefit to wrap that into {{ByteBuffer}}?
bq. Please put braces around "if" statements.
Done
bq. 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.
As it's direclty accessed by a {{SpanReceiver}} it depends how the
{{SpanReceiver}} is being used and how it uses it.
The current implementation's access is through {{Runnable.run()}} so it should
be fine.
> 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)
