zookeeper-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "maoling (Jira)" <j...@apache.org>
Subject [jira] [Commented] (ZOOKEEPER-102) Need to replace Jute with supported code
Date Tue, 24 Sep 2019 11:05:00 GMT

    [ https://issues.apache.org/jira/browse/ZOOKEEPER-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16936668#comment-16936668

maoling commented on ZOOKEEPER-102:

_*1 --->shall we want an intermediate stage support both jute and the other serialization

   It may be unrealistic and too complicated.

2. Since these are huge change work, so we should do a sufficient survey about the benefit(especially
performance gain) of moving to the third-party serialize component.

   I prefer to thrift, hbase uses that way. Thrift has better performance and better java
support than PB. Of course, I have not tested for this :)

3. For the experience from other project:

    etcd v2 uses the simple restful/http way, after moving to GRPC in etcd v3, etcd v3 cannot
communicate with v2 server anymore. If we need to replace jute, we may do this compatibility broken work
in the 4.0.0


> Need to replace Jute with supported code
> ----------------------------------------
>                 Key: ZOOKEEPER-102
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-102
>             Project: ZooKeeper
>          Issue Type: Improvement
>            Reporter: Benjamin Reed
>            Priority: Major
>             Fix For: 4.0.0
> ZooKeeper currently uses Jute to serialize objects to put on the wire and on disk. We
pulled Jute out of Hadoop and added a C binding. Both versions of Jute have evolved (although
Hadoop still doesn't have a C binding). It would be nice to use a more standard serialization
library. Some options include Thrift or Google's protocol buffers.
> Our main requirements would be Java and C bindings and good performance. (For example,
serializing to XML would give us incredibly bad performance and would not be acceptible!)

This message was sent by Atlassian Jira

View raw message