Adrian Cole
Adrian Cole
in java we use metrics for this, and the metrics handler could be overridden to use console if you wanted. granted in java, typically the underlying http libraries can log...
as logging can flood the console, we only handle first error at warn level (this is in the async reporter) then FINE afterwards (similar to DEBUG level) https://github.com/openzipkin/zipkin-reporter-java/pull/155
hi. I haven't been active on this project because I can barely compile csharp. I was pulled to another issue due to it being cross posted and sadly it declined...
as far as I can tell your code looks like it is correct. I dont know the nature of Guid but the end goal is to parse and generate 128...
sure.. we can look into this if spark 3 doesn't implicitly fix this via scala version or something. thanks!
https://github.com/elastic/elasticsearch-hadoop/pull/1521 is the most recent development. Only elasticsearch is holding this back
food for thought but single span kafka messages are very much a v1 legacy thing. all transports should accept list messages even if there is additional buffering at the transport...
There was some efforts by yelp back in the day that ultimately led to sizing messages being more efficient even if our storage layer wasn't also more efficient if sent...
> > That's an interesting idea. This would make the serializers/senders quite > a bit more complex though - since the size isn't known until after > serialization, the sender...
I would not combine the two honestly, unless it is usual to do that. just make a subtype of getter/setter which gets the point across?