[
https://issues.apache.org/jira/browse/BOOKKEEPER-582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13626325#comment-13626325
]
Sijie Guo commented on BOOKKEEPER-582:
--------------------------------------
{quote}
If the protobuf conspires to have a value opCode for an add, but the request
isn't an add, for example, this will likely crash the server when trying to
read the packet.
{quote}
if that, an evil client implementation could crash the server. it is a bug for
the old server, everyone could produce such client to crash that server. I
don't think it would be a concern, if we could guarantee the new client would
not crash the old server but just receiving bad version response, isn't it?
no matter what protobuf changes are accepted in trunk, I am thinking that we
should not tightly bound with protobuf. There is too much overhead using
protobuf. taking the publisher/delivery flow in Hedwig in consideration, a
message received in netty as bytes buffer, then deserialized into a Message
(protobuf) object, constructed a new Message (protobuf) object with new message
seq id, converted into a bytes array, formed another protobuf request in
bookkeeper. Lots of objects are generated and lots of memory copies during the
life-cycle of messages, which would cause gc issue for a higher publish
throughput.
Tightly bound with protobuf is bad for evaluating and providing more efficient
and zero-copy client implementation. I would suggest we should separate the
request serialization and response deserialization into a thin part rather than
modifying PCBC to use protobuf objects, so it would be easy to allow different
protocol implementation and to evaluate efficient zero-copy client in future.
> Make bookie and client use protobuf for requests (non-wire part)
> ----------------------------------------------------------------
>
> Key: BOOKKEEPER-582
> URL: https://issues.apache.org/jira/browse/BOOKKEEPER-582
> Project: Bookkeeper
> Issue Type: Sub-task
> Reporter: Ivan Kelly
> Assignee: Ivan Kelly
> Fix For: 4.3.0
>
> Attachments:
> 0002-BOOKKEEPER-582-Make-bookie-and-client-use-protobuf-f.patch,
> 0002-BOOKKEEPER-582-Make-bookie-and-client-use-protobuf-f.patch,
> 0002-BOOKKEEPER-582-Make-bookie-and-client-use-protobuf-f.patch,
> 0003-BOOKKEEPER-582-Make-bookie-and-client-use-protobuf-f.patch
>
>
> Make the client and the bookie use protobufs internally. This is the first
> step to using protobufs on the wire, but for the moment, BookieRequestHandler
> decodes the old wire protocol into the protobuf messages. Once this is in,
> enabling on the wire will be very simple, and the old manual serialization
> can be made "legacy" (still supported, but deprecated).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira