[
https://issues.apache.org/jira/browse/ZOOKEEPER-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16977000#comment-16977000
]
Jordan Zimmerman edited comment on ZOOKEEPER-102 at 11/18/19 11:57 PM:
-----------------------------------------------------------------------
Here's a stab at a game plan:
* Step 1 - remove use of Jute-based ByteBuffers from server-side code -
replace with deserialized/real objects
** ZooKeeperServer.processConnectRequest()
** ZooKeeperServer.processPacket()
** ZooKeeperServer.processSasl()
** Request.request -- serialized client requests - this is the big one - is
used everywhere
** ServerCnxn.sendBuffer()
** ServerCnxn.serialize()
** probably a few other places
* Step 2 - Decision - Consider replacing Jute data structures with bespoke ZK
server data structures
** If Jute classes are retained, there's nothing more to do refactoring-wise
** Unless Jute classes are removed, upgrading/widening protocol will be
difficult
** transaction/snapshot files - maybe these stay Jute?
** quorum/internal protocol - leave as is?
* Step 3 - (Depends on Step 2)
** Improve APIs
** 64 bit versions
** Remove magic numbers, etc.
** Etc.
* Step 4 - (likely can be done in parallel)
** Implement gRPC version of ServerCnxnFactory and ServerCnxn
** Use Randgalt proof of concept as base
** Etc.
* Step 5
** Alongside step 4, develop clients in a few target languages (golang, ???)
** Make sure server support works for a variety of languages
** Tests, etc.
was (Author: randgalt):
Here's a stab at a game plan:
* Step 1 - remove use of Jute-based ByteBuffers from server-side code -
replace with deserialized/real objects
** ZooKeeperServer.processConnectRequest()
** ZooKeeperServer.processPacket()
** ZooKeeperServer.processSasl()
** Request.request -- serialized client requests - this is the big one - is
used everywhere
** ServerCnxn.sendBuffer()
** ServerCnxn.serialize()
** probably a few other places
* Step 2 - Decision - Consider replacing Jute data structures with bespoke ZK
server data structures
** If Jute classes are retained, there's nothing more to do refactoring-wise
** Unless Jute classes are removed, upgrading/widening protocol will be
difficult
** transaction/snapshot files - maybe these stay Jute?
** quorum/internal protocol - leave as is?
* Step 3 - (Depends on Step 2)
** Improve APIs
** 64 bit versions
** Remove magic numbers, etc.
** Etc.
* Step 4 - (likely can be done in parallel)
** Implement gRPC version of ServerCnxnFactory and ServerCnxn
** Use Randgalt proof of concept as base
** Etc.
* Step 5
** Alongside step 4, develop clients in a few target languages (golang, ???)
** Make sure server support works for a variety of languages
** Tests, etc.
> 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
> Assignee: Jordan Zimmerman
> 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
(v8.3.4#803005)
