[
https://issues.apache.org/jira/browse/HTRACE-164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14530021#comment-14530021
]
Elliott Clark commented on HTRACE-164:
--------------------------------------
bq.Elliot, there is nothing about this patch that impacts you at all.
That's neither constructive nor correct.
bq.You don't use htraced, and this patch only affects htraced.
You have no idea what's going on in my deploys. Also I'm with this project so
that's just incorrect.
bq.And we can't bundle most dependencies because of license incompatibilities
Thrift's apache. With only bsd dependencies.
Grpc is bsd. With only bsd dependencies
So both of the suggestions that's I've put forward are totally linkable in any
fashion that you want, with static linking being what I would prefer.
bq.Again, HTrace is not Hadoop.
No it's not but lets be honest about what the first 200 installs of this
software are going to be. The first uses will all be in the
hadoop/hbase/phoenix world. If you make life hard for the first users, none are
going to be compelled to use this other places.
I can't see any benefit to msgpack:
* Fewer users of it
**
https://www.google.com/trends/explore#q=msgpack%2C%20protobuf%2C%20apache%20thrift&cmpt=q&tz=
* No proven perf wins vs thift or protobuf
** Thrift-compact is smaller over the wire.
** Thrift-binary is equal in speed.
* another dep on the server that's not one of the ones already in use by the
systems using htrace.
* A hand coded serialization format on the client side.
** Writables deja vu
* Hard coded limit on span data size.
bq.Using something just because Hadoop uses it is practically the definition of
NIH.
I'm suggesting we use something that's used in large environments with lots of
users and lots of developers. The htrace project doesn't have to create a new
rpc format. We have no requirements that couldn't be answered by an already
existing stack. I'm literally saying: Don't invent something here just for
htrace.
bq.If you think msgpack is a plague upon mankind and you want to write your own
JSON client for htraced
I think that adding msgpack doesn't gain enough to make the added complexity on
the client and the server worth it. gzipped json is pretty fast. If we need
faster and need to have an rpc then using an already existing rpc stack makes
more sense.
I don't think that htrace is even close to mature enough to be encouraging
fracturing the community. There shouldn't be one format for java and one for
some C.
bq. We would love to support more span receivers there.
That leads to an explosion of complexity that no one wins from.
bq.Let's be constructive here.
I've suggested multiple alternatives with technical reasoning around why they
would be better. I'm -1 on this patch for the technical reasons above.
> htrace hrpc: use msgpack for serialization
> ------------------------------------------
>
> Key: HTRACE-164
> URL: https://issues.apache.org/jira/browse/HTRACE-164
> Project: HTrace
> Issue Type: Bug
> Affects Versions: 3.2.0
> Reporter: Colin Patrick McCabe
> Assignee: Colin Patrick McCabe
> Attachments: HTRACE-164.002.patch
>
>
> htrace HRPC should use msgpack for serialization. Messages serialized using
> msgpack use less space on the wire and use less CPU time to encode. The CMP
> library allows us to include msgpack support easily in the htrace C client.
> There is also good Java and Golang support available.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
