You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@bookkeeper.apache.org by Sijie Guo <gu...@gmail.com> on 2014/02/10 08:11:50 UTC

Review Request 17895: BOOKKEEPER-582: protobuf support for bookkeeper

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/17895/
-----------------------------------------------------------

Review request for bookkeeper and Ivan Kelly.


Bugs: BOOKKEEPER-582
    https://issues.apache.org/jira/browse/BOOKKEEPER-582


Repository: bookkeeper-git


Description
-------

- introducing protobuf support for bookkeeper
- for server: introduce packet processor / EnDecoder for different protocol supports
- for client: change PCBC to use protobuf to send requests
- misc changes for protobuf support

(bookie server is able for backward compatibility) 


Diffs
-----

  bookkeeper-server/src/main/java/org/apache/bookkeeper/bookie/IndexInMemPageMgr.java 56487aa 
  bookkeeper-server/src/main/java/org/apache/bookkeeper/client/LedgerChecker.java 962f3a3 
  bookkeeper-server/src/main/java/org/apache/bookkeeper/client/PendingReadOp.java 241fdbb 
  bookkeeper-server/src/main/java/org/apache/bookkeeper/processor/RequestProcessor.java 241f369 
  bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieProtoEncoding.java 1154047 
  bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestHandler.java b922a82 
  bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestProcessor.java 8155b22 
  bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookkeeperProtocol.java PRE-CREATION 
  bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBase.java PRE-CREATION 
  bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBaseV3.java PRE-CREATION 
  bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PerChannelBookieClient.java 0757f87 
  bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessor.java PRE-CREATION 
  bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessorV3.java PRE-CREATION 
  bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessor.java PRE-CREATION 
  bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessorV3.java PRE-CREATION 
  bookkeeper-server/src/main/proto/BookkeeperProtocol.proto PRE-CREATION 
  bookkeeper-server/src/main/resources/findbugsExclude.xml 8404e3f 
  bookkeeper-server/src/test/java/org/apache/bookkeeper/proto/TestProtoVersions.java 5fcc445 
  bookkeeper-server/src/test/java/org/apache/bookkeeper/replication/AuditorPeriodicCheckTest.java 3f8496f 
  bookkeeper-server/src/test/java/org/apache/bookkeeper/test/BookieClientTest.java bc05229 
  bookkeeper-server/src/test/java/org/apache/bookkeeper/test/TestBackwardCompat.java 8376b46 

Diff: https://reviews.apache.org/r/17895/diff/


Testing
-------

unit tests. backward tests.


Thanks,

Sijie Guo

Re: Review Request 17895: BOOKKEEPER-582: protobuf support for bookkeeper

Posted by Sijie Guo <gu...@gmail.com>.


> On March 24, 2014, 11:55 a.m., Rakesh R wrote:
> > bookkeeper-server/src/main/java/org/apache/bookkeeper/client/PendingReadOp.java, line 199
> > <https://reviews.apache.org/r/17895/diff/1/?file=481708#file481708line199>
> >
> >     Its good to modify the java comments as well as the logging which describes the new condition. Also to understand more about the issue, can you please point me to any test cases for these changes...

modified


> On March 24, 2014, 11:55 a.m., Rakesh R wrote:
> > bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBaseV3.java, line 1
> > <https://reviews.apache.org/r/17895/diff/1/?file=481715#file481715line1>
> >
> >     license header is missing no ?

added


> On March 24, 2014, 11:55 a.m., Rakesh R wrote:
> > bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PerChannelBookieClient.java, line 498
> > <https://reviews.apache.org/r/17895/diff/1/?file=481716#file481716line498>
> >
> >     Can we avoid String concatenation in logs ?

done


> On March 24, 2014, 11:55 a.m., Rakesh R wrote:
> > bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PerChannelBookieClient.java, line 726
> > <https://reviews.apache.org/r/17895/diff/1/?file=481716#file481716line726>
> >
> >     Avoid string concatenation in logs, have seen many such things in the patch. Could you please take care this.

done


> On March 24, 2014, 11:55 a.m., Rakesh R wrote:
> > bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PerChannelBookieClient.java, line 447
> > <https://reviews.apache.org/r/17895/diff/1/?file=481716#file481716line447>
> >
> >     Can we avoid String concatenation in logs ?

since this task is for protocol change. so I just left the logs as unchanged as possible. but anyway, changed to {} in new patch.


> On March 24, 2014, 11:55 a.m., Rakesh R wrote:
> > bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PerChannelBookieClient.java, line 764
> > <https://reviews.apache.org/r/17895/diff/1/?file=481716#file481716line764>
> >
> >     Avoid String concatenation in logs.

done


> On March 24, 2014, 11:55 a.m., Rakesh R wrote:
> > bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessorV3.java, line 1
> > <https://reviews.apache.org/r/17895/diff/1/?file=481720#file481720line1>
> >
> >     license header is missing.

done


- Sijie


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/17895/#review38282
-----------------------------------------------------------


On April 21, 2014, 5:58 a.m., Sijie Guo wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/17895/
> -----------------------------------------------------------
> 
> (Updated April 21, 2014, 5:58 a.m.)
> 
> 
> Review request for bookkeeper and Ivan Kelly.
> 
> 
> Bugs: BOOKKEEPER-582
>     https://issues.apache.org/jira/browse/BOOKKEEPER-582
> 
> 
> Repository: bookkeeper-git
> 
> 
> Description
> -------
> 
> - introducing protobuf support for bookkeeper
> - for server: introduce packet processor / EnDecoder for different protocol supports
> - for client: change PCBC to use protobuf to send requests
> - misc changes for protobuf support
> 
> (bookie server is able for backward compatibility) 
> 
> 
> Diffs
> -----
> 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/bookie/IndexInMemPageMgr.java 56487aa 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/LedgerChecker.java 28e23d6 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/PendingReadOp.java fb36b90 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/processor/RequestProcessor.java 241f369 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieProtoEncoding.java 1154047 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestHandler.java b922a82 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestProcessor.java 8155b22 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookkeeperProtocol.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBase.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBaseV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PerChannelBookieClient.java a10f7d5 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/proto/BookkeeperProtocol.proto PRE-CREATION 
>   bookkeeper-server/src/main/resources/findbugsExclude.xml 97a6156 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/proto/TestProtoVersions.java 5fcc445 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/replication/AuditorPeriodicCheckTest.java 3f8496f 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/BookieClientTest.java bc05229 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/TestBackwardCompat.java 8376b46 
> 
> Diff: https://reviews.apache.org/r/17895/diff/
> 
> 
> Testing
> -------
> 
> unit tests. backward tests.
> 
> 
> Thanks,
> 
> Sijie Guo
> 
>

Re: Review Request 17895: BOOKKEEPER-582: protobuf support for bookkeeper

Posted by Rakesh R <ra...@huawei.com>.

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/17895/#review38282
-----------------------------------------------------------


Thanks Sijie, its really awsome! I just have few minor comments, please see it.


bookkeeper-server/src/main/java/org/apache/bookkeeper/client/PendingReadOp.java
<https://reviews.apache.org/r/17895/#comment70327>

    Its good to modify the java comments as well as the logging which describes the new condition. Also to understand more about the issue, can you please point me to any test cases for these changes...



bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBaseV3.java
<https://reviews.apache.org/r/17895/#comment70328>

    license header is missing no ?



bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PerChannelBookieClient.java
<https://reviews.apache.org/r/17895/#comment70331>

    Can we avoid String concatenation in logs ?



bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PerChannelBookieClient.java
<https://reviews.apache.org/r/17895/#comment70332>

    Can we avoid String concatenation in logs ?



bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PerChannelBookieClient.java
<https://reviews.apache.org/r/17895/#comment70333>

    Avoid string concatenation in logs, have seen many such things in the patch. Could you please take care this.



bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PerChannelBookieClient.java
<https://reviews.apache.org/r/17895/#comment70330>

    Avoid String concatenation in logs.



bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessorV3.java
<https://reviews.apache.org/r/17895/#comment70334>

    license header is missing.


- Rakesh R


On Feb. 10, 2014, 7:11 a.m., Sijie Guo wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/17895/
> -----------------------------------------------------------
> 
> (Updated Feb. 10, 2014, 7:11 a.m.)
> 
> 
> Review request for bookkeeper and Ivan Kelly.
> 
> 
> Bugs: BOOKKEEPER-582
>     https://issues.apache.org/jira/browse/BOOKKEEPER-582
> 
> 
> Repository: bookkeeper-git
> 
> 
> Description
> -------
> 
> - introducing protobuf support for bookkeeper
> - for server: introduce packet processor / EnDecoder for different protocol supports
> - for client: change PCBC to use protobuf to send requests
> - misc changes for protobuf support
> 
> (bookie server is able for backward compatibility) 
> 
> 
> Diffs
> -----
> 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/bookie/IndexInMemPageMgr.java 56487aa 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/LedgerChecker.java 962f3a3 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/PendingReadOp.java 241fdbb 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/processor/RequestProcessor.java 241f369 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieProtoEncoding.java 1154047 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestHandler.java b922a82 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestProcessor.java 8155b22 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookkeeperProtocol.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBase.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBaseV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PerChannelBookieClient.java 0757f87 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/proto/BookkeeperProtocol.proto PRE-CREATION 
>   bookkeeper-server/src/main/resources/findbugsExclude.xml 8404e3f 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/proto/TestProtoVersions.java 5fcc445 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/replication/AuditorPeriodicCheckTest.java 3f8496f 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/BookieClientTest.java bc05229 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/TestBackwardCompat.java 8376b46 
> 
> Diff: https://reviews.apache.org/r/17895/diff/
> 
> 
> Testing
> -------
> 
> unit tests. backward tests.
> 
> 
> Thanks,
> 
> Sijie Guo
> 
>

Re: Review Request 17895: BOOKKEEPER-582: protobuf support for bookkeeper

Posted by Sijie Guo <gu...@gmail.com>.


> On March 19, 2014, 10:49 a.m., fpj wrote:
> > This is a great, I just have a few minor points and clarifications below.

Thanks Flavio for reviewing. Will address your comments.


- Sijie


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/17895/#review37545
-----------------------------------------------------------


On Feb. 10, 2014, 7:11 a.m., Sijie Guo wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/17895/
> -----------------------------------------------------------
> 
> (Updated Feb. 10, 2014, 7:11 a.m.)
> 
> 
> Review request for bookkeeper and Ivan Kelly.
> 
> 
> Bugs: BOOKKEEPER-582
>     https://issues.apache.org/jira/browse/BOOKKEEPER-582
> 
> 
> Repository: bookkeeper-git
> 
> 
> Description
> -------
> 
> - introducing protobuf support for bookkeeper
> - for server: introduce packet processor / EnDecoder for different protocol supports
> - for client: change PCBC to use protobuf to send requests
> - misc changes for protobuf support
> 
> (bookie server is able for backward compatibility) 
> 
> 
> Diffs
> -----
> 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/bookie/IndexInMemPageMgr.java 56487aa 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/LedgerChecker.java 962f3a3 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/PendingReadOp.java 241fdbb 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/processor/RequestProcessor.java 241f369 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieProtoEncoding.java 1154047 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestHandler.java b922a82 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestProcessor.java 8155b22 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookkeeperProtocol.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBase.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBaseV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PerChannelBookieClient.java 0757f87 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/proto/BookkeeperProtocol.proto PRE-CREATION 
>   bookkeeper-server/src/main/resources/findbugsExclude.xml 8404e3f 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/proto/TestProtoVersions.java 5fcc445 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/replication/AuditorPeriodicCheckTest.java 3f8496f 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/BookieClientTest.java bc05229 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/TestBackwardCompat.java 8376b46 
> 
> Diff: https://reviews.apache.org/r/17895/diff/
> 
> 
> Testing
> -------
> 
> unit tests. backward tests.
> 
> 
> Thanks,
> 
> Sijie Guo
> 
>

Re: Review Request 17895: BOOKKEEPER-582: protobuf support for bookkeeper

Posted by Sijie Guo <gu...@gmail.com>.


> On March 19, 2014, 10:49 a.m., fpj wrote:
> > This is a great, I just have a few minor points and clarifications below.
> 
> Sijie Guo wrote:
>     Thanks Flavio for reviewing. Will address your comments.

sorry for late response. comments inline


> On March 19, 2014, 10:49 a.m., fpj wrote:
> > bookkeeper-server/src/main/java/org/apache/bookkeeper/client/LedgerChecker.java, line 131
> > <https://reviews.apache.org/r/17895/diff/1/?file=481707#file481707line131>
> >
> >     Just to confirm, this is an improvement unrelated to this issue, yes?

yup. it is unrelated. but since I generated the patch by diffing our branch with trunk branch, so I didn't split them.


> On March 19, 2014, 10:49 a.m., fpj wrote:
> > bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieProtoEncoding.java, line 41
> > <https://reviews.apache.org/r/17895/diff/1/?file=481710#file481710line41>
> >
> >     It is good to use the version number (PreV3, V3) to differentiate parts of the code that serve different versions. This is a bit messy, though, because the version alone doesn't say what change actually triggered the code split. I was wondering if it makes sense to use ProtoBuf or PB, instead of V3, just to make it a bit more clear what change it is referring to in version 3.

could I have a separated task to do renaming?


> On March 19, 2014, 10:49 a.m., fpj wrote:
> > bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookkeeperProtocol.java, line 1
> > <https://reviews.apache.org/r/17895/diff/1/?file=481713#file481713line1>
> >
> >     I think we still need to add the license header, no?

added


> On March 19, 2014, 10:49 a.m., fpj wrote:
> > bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessorV3.java, line 69
> > <https://reviews.apache.org/r/17895/diff/1/?file=481718#file481718line69>
> >
> >     This comment is repeated from the previous file. Do we need a jira for this todo?

created https://issues.apache.org/jira/browse/BOOKKEEPER-748


> On March 19, 2014, 10:49 a.m., fpj wrote:
> > bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessor.java, line 51
> > <https://reviews.apache.org/r/17895/diff/1/?file=481719#file481719line51>
> >
> >     "... running in read-only mode..."

fixed


> On March 19, 2014, 10:49 a.m., fpj wrote:
> > bookkeeper-server/src/test/java/org/apache/bookkeeper/test/TestBackwardCompat.java, line 530
> > <https://reviews.apache.org/r/17895/diff/1/?file=481726#file481726line530>
> >
> >     Just to confirm, are we relying on the fact that compatibility with 4.1.0 implies compatibility with 4.2.0? I'm basically trying to understand why we don't need to add a new test case to test backward compatibility.

there is no change on protocol between 4.1.0 and 4.2.0. so we could use 4.1.0 implies compatibility with 4.2.0. but if adding 4.2.0 would make it clear, I could create a jira for it.


- Sijie


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/17895/#review37545
-----------------------------------------------------------


On April 21, 2014, 5:58 a.m., Sijie Guo wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/17895/
> -----------------------------------------------------------
> 
> (Updated April 21, 2014, 5:58 a.m.)
> 
> 
> Review request for bookkeeper and Ivan Kelly.
> 
> 
> Bugs: BOOKKEEPER-582
>     https://issues.apache.org/jira/browse/BOOKKEEPER-582
> 
> 
> Repository: bookkeeper-git
> 
> 
> Description
> -------
> 
> - introducing protobuf support for bookkeeper
> - for server: introduce packet processor / EnDecoder for different protocol supports
> - for client: change PCBC to use protobuf to send requests
> - misc changes for protobuf support
> 
> (bookie server is able for backward compatibility) 
> 
> 
> Diffs
> -----
> 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/bookie/IndexInMemPageMgr.java 56487aa 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/LedgerChecker.java 28e23d6 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/PendingReadOp.java fb36b90 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/processor/RequestProcessor.java 241f369 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieProtoEncoding.java 1154047 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestHandler.java b922a82 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestProcessor.java 8155b22 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookkeeperProtocol.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBase.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBaseV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PerChannelBookieClient.java a10f7d5 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/proto/BookkeeperProtocol.proto PRE-CREATION 
>   bookkeeper-server/src/main/resources/findbugsExclude.xml 97a6156 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/proto/TestProtoVersions.java 5fcc445 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/replication/AuditorPeriodicCheckTest.java 3f8496f 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/BookieClientTest.java bc05229 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/TestBackwardCompat.java 8376b46 
> 
> Diff: https://reviews.apache.org/r/17895/diff/
> 
> 
> Testing
> -------
> 
> unit tests. backward tests.
> 
> 
> Thanks,
> 
> Sijie Guo
> 
>

Re: Review Request 17895: BOOKKEEPER-582: protobuf support for bookkeeper

Posted by Sijie Guo <gu...@gmail.com>.


> On March 19, 2014, 10:49 a.m., fpj wrote:
> > bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessor.java, line 67
> > <https://reviews.apache.org/r/17895/diff/1/?file=481717#file481717line67>
> >
> >     Should we create a jira for this todo?

created https://issues.apache.org/jira/browse/BOOKKEEPER-748


- Sijie


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/17895/#review37545
-----------------------------------------------------------


On April 21, 2014, 5:58 a.m., Sijie Guo wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/17895/
> -----------------------------------------------------------
> 
> (Updated April 21, 2014, 5:58 a.m.)
> 
> 
> Review request for bookkeeper and Ivan Kelly.
> 
> 
> Bugs: BOOKKEEPER-582
>     https://issues.apache.org/jira/browse/BOOKKEEPER-582
> 
> 
> Repository: bookkeeper-git
> 
> 
> Description
> -------
> 
> - introducing protobuf support for bookkeeper
> - for server: introduce packet processor / EnDecoder for different protocol supports
> - for client: change PCBC to use protobuf to send requests
> - misc changes for protobuf support
> 
> (bookie server is able for backward compatibility) 
> 
> 
> Diffs
> -----
> 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/bookie/IndexInMemPageMgr.java 56487aa 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/LedgerChecker.java 28e23d6 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/PendingReadOp.java fb36b90 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/processor/RequestProcessor.java 241f369 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieProtoEncoding.java 1154047 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestHandler.java b922a82 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestProcessor.java 8155b22 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookkeeperProtocol.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBase.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBaseV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PerChannelBookieClient.java a10f7d5 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/proto/BookkeeperProtocol.proto PRE-CREATION 
>   bookkeeper-server/src/main/resources/findbugsExclude.xml 97a6156 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/proto/TestProtoVersions.java 5fcc445 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/replication/AuditorPeriodicCheckTest.java 3f8496f 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/BookieClientTest.java bc05229 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/TestBackwardCompat.java 8376b46 
> 
> Diff: https://reviews.apache.org/r/17895/diff/
> 
> 
> Testing
> -------
> 
> unit tests. backward tests.
> 
> 
> Thanks,
> 
> Sijie Guo
> 
>

Re: Review Request 17895: BOOKKEEPER-582: protobuf support for bookkeeper

Posted by fp...@apache.org.

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/17895/#review37545
-----------------------------------------------------------

Ship it!


This is a great, I just have a few minor points and clarifications below.


bookkeeper-server/src/main/java/org/apache/bookkeeper/client/LedgerChecker.java
<https://reviews.apache.org/r/17895/#comment69348>

    Just to confirm, this is an improvement unrelated to this issue, yes?



bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieProtoEncoding.java
<https://reviews.apache.org/r/17895/#comment69349>

    It is good to use the version number (PreV3, V3) to differentiate parts of the code that serve different versions. This is a bit messy, though, because the version alone doesn't say what change actually triggered the code split. I was wondering if it makes sense to use ProtoBuf or PB, instead of V3, just to make it a bit more clear what change it is referring to in version 3.   



bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookkeeperProtocol.java
<https://reviews.apache.org/r/17895/#comment69139>

    I think we still need to add the license header, no?



bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessor.java
<https://reviews.apache.org/r/17895/#comment69345>

    Should we create a jira for this todo?



bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessorV3.java
<https://reviews.apache.org/r/17895/#comment69346>

    This comment is repeated from the previous file. Do we need a jira for this todo?



bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessor.java
<https://reviews.apache.org/r/17895/#comment69347>

    "... running in read-only mode..."



bookkeeper-server/src/test/java/org/apache/bookkeeper/test/TestBackwardCompat.java
<https://reviews.apache.org/r/17895/#comment69350>

    Just to confirm, are we relying on the fact that compatibility with 4.1.0 implies compatibility with 4.2.0? I'm basically trying to understand why we don't need to add a new test case to test backward compatibility.


- fpj


On Feb. 10, 2014, 7:11 a.m., Sijie Guo wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/17895/
> -----------------------------------------------------------
> 
> (Updated Feb. 10, 2014, 7:11 a.m.)
> 
> 
> Review request for bookkeeper and Ivan Kelly.
> 
> 
> Bugs: BOOKKEEPER-582
>     https://issues.apache.org/jira/browse/BOOKKEEPER-582
> 
> 
> Repository: bookkeeper-git
> 
> 
> Description
> -------
> 
> - introducing protobuf support for bookkeeper
> - for server: introduce packet processor / EnDecoder for different protocol supports
> - for client: change PCBC to use protobuf to send requests
> - misc changes for protobuf support
> 
> (bookie server is able for backward compatibility) 
> 
> 
> Diffs
> -----
> 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/bookie/IndexInMemPageMgr.java 56487aa 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/LedgerChecker.java 962f3a3 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/PendingReadOp.java 241fdbb 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/processor/RequestProcessor.java 241f369 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieProtoEncoding.java 1154047 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestHandler.java b922a82 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestProcessor.java 8155b22 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookkeeperProtocol.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBase.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBaseV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PerChannelBookieClient.java 0757f87 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/proto/BookkeeperProtocol.proto PRE-CREATION 
>   bookkeeper-server/src/main/resources/findbugsExclude.xml 8404e3f 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/proto/TestProtoVersions.java 5fcc445 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/replication/AuditorPeriodicCheckTest.java 3f8496f 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/BookieClientTest.java bc05229 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/TestBackwardCompat.java 8376b46 
> 
> Diff: https://reviews.apache.org/r/17895/diff/
> 
> 
> Testing
> -------
> 
> unit tests. backward tests.
> 
> 
> Thanks,
> 
> Sijie Guo
> 
>

Re: Review Request 17895: BOOKKEEPER-582: protobuf support for bookkeeper

Posted by Sijie Guo <gu...@gmail.com>.


> On April 24, 2014, 12:19 p.m., Ivan Kelly wrote:
> > bookkeeper-server/src/main/proto/BookkeeperProtocol.proto, line 81
> > <https://reviews.apache.org/r/17895/diff/2/?file=563033#file563033line81>
> >
> >     ledgerId and entryId should be optional in all requests. It may be the case, that how we specify them changes in the future (like when we flatten the metadata), so it would be good to leave that possibility open.
> 
> Sijie Guo wrote:
>     for all existing reads/writes protocol, the ledgerId and entryId are required. I am not sure how u will change the protocol by flatten the metadata. but I guess that will be pretty new protocol. if so, it would be better to add new request type, so we will not break any existing systems or making it being complicated.
> 
> Ivan Kelly wrote:
>     Im not sure how it will change either. What I'm requesting is that the protobuf protocol doesnt lock us in to how we are doing it now forever.
> 
> Ivan Kelly wrote:
>     actually for a concrete example, lets say we want to do a read request for a whole ledger, from bookie A we request all entries, but it doesnt have every 3rd entry due to striping. In the case we can request all entrys from the ledger with entryid modulo 3 from bookie B. In this case, what would I put in the _required_ entry id firld for the read to bookie B?

as I said, doesn't it sound like a new read protocol?


- Sijie


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/17895/#review41281
-----------------------------------------------------------


On April 24, 2014, 7:43 a.m., Sijie Guo wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/17895/
> -----------------------------------------------------------
> 
> (Updated April 24, 2014, 7:43 a.m.)
> 
> 
> Review request for bookkeeper and Ivan Kelly.
> 
> 
> Bugs: BOOKKEEPER-582
>     https://issues.apache.org/jira/browse/BOOKKEEPER-582
> 
> 
> Repository: bookkeeper-git
> 
> 
> Description
> -------
> 
> - introducing protobuf support for bookkeeper
> - for server: introduce packet processor / EnDecoder for different protocol supports
> - for client: change PCBC to use protobuf to send requests
> - misc changes for protobuf support
> 
> (bookie server is able for backward compatibility) 
> 
> 
> Diffs
> -----
> 
>   bookkeeper-server/pom.xml ebc1198 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/bookie/IndexInMemPageMgr.java 56487aa 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/LedgerChecker.java 28e23d6 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/PendingReadOp.java fb36b90 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/processor/RequestProcessor.java 241f369 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieProtoEncoding.java 1154047 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestHandler.java b922a82 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestProcessor.java 8155b22 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookkeeperProtocol.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBase.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBaseV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PerChannelBookieClient.java a10f7d5 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/proto/BookkeeperProtocol.proto PRE-CREATION 
>   bookkeeper-server/src/main/resources/findbugsExclude.xml 97a6156 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/proto/TestProtoVersions.java 5fcc445 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/replication/AuditorPeriodicCheckTest.java 3f8496f 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/BookieClientTest.java bc05229 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/TestBackwardCompat.java 8376b46 
>   compat-deps/bookkeeper-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/hedwig-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/pom.xml f79582d 
>   hedwig-server/pom.xml 06cf01c 
>   hedwig-server/src/test/java/org/apache/hedwig/server/TestBackwardCompat.java 8da109e 
> 
> Diff: https://reviews.apache.org/r/17895/diff/
> 
> 
> Testing
> -------
> 
> unit tests. backward tests.
> 
> 
> Thanks,
> 
> Sijie Guo
> 
>

Re: Review Request 17895: BOOKKEEPER-582: protobuf support for bookkeeper

Posted by Ivan Kelly <iv...@apache.org>.


> On April 24, 2014, 12:19 p.m., Ivan Kelly wrote:
> > bookkeeper-server/src/main/proto/BookkeeperProtocol.proto, line 81
> > <https://reviews.apache.org/r/17895/diff/2/?file=563033#file563033line81>
> >
> >     ledgerId and entryId should be optional in all requests. It may be the case, that how we specify them changes in the future (like when we flatten the metadata), so it would be good to leave that possibility open.
> 
> Sijie Guo wrote:
>     for all existing reads/writes protocol, the ledgerId and entryId are required. I am not sure how u will change the protocol by flatten the metadata. but I guess that will be pretty new protocol. if so, it would be better to add new request type, so we will not break any existing systems or making it being complicated.

Im not sure how it will change either. What I'm requesting is that the protobuf protocol doesnt lock us in to how we are doing it now forever.


- Ivan


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/17895/#review41281
-----------------------------------------------------------


On April 24, 2014, 7:43 a.m., Sijie Guo wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/17895/
> -----------------------------------------------------------
> 
> (Updated April 24, 2014, 7:43 a.m.)
> 
> 
> Review request for bookkeeper and Ivan Kelly.
> 
> 
> Bugs: BOOKKEEPER-582
>     https://issues.apache.org/jira/browse/BOOKKEEPER-582
> 
> 
> Repository: bookkeeper-git
> 
> 
> Description
> -------
> 
> - introducing protobuf support for bookkeeper
> - for server: introduce packet processor / EnDecoder for different protocol supports
> - for client: change PCBC to use protobuf to send requests
> - misc changes for protobuf support
> 
> (bookie server is able for backward compatibility) 
> 
> 
> Diffs
> -----
> 
>   bookkeeper-server/pom.xml ebc1198 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/bookie/IndexInMemPageMgr.java 56487aa 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/LedgerChecker.java 28e23d6 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/PendingReadOp.java fb36b90 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/processor/RequestProcessor.java 241f369 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieProtoEncoding.java 1154047 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestHandler.java b922a82 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestProcessor.java 8155b22 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookkeeperProtocol.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBase.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBaseV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PerChannelBookieClient.java a10f7d5 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/proto/BookkeeperProtocol.proto PRE-CREATION 
>   bookkeeper-server/src/main/resources/findbugsExclude.xml 97a6156 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/proto/TestProtoVersions.java 5fcc445 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/replication/AuditorPeriodicCheckTest.java 3f8496f 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/BookieClientTest.java bc05229 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/TestBackwardCompat.java 8376b46 
>   compat-deps/bookkeeper-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/hedwig-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/pom.xml f79582d 
>   hedwig-server/pom.xml 06cf01c 
>   hedwig-server/src/test/java/org/apache/hedwig/server/TestBackwardCompat.java 8da109e 
> 
> Diff: https://reviews.apache.org/r/17895/diff/
> 
> 
> Testing
> -------
> 
> unit tests. backward tests.
> 
> 
> Thanks,
> 
> Sijie Guo
> 
>

Re: Review Request 17895: BOOKKEEPER-582: protobuf support for bookkeeper

Posted by Rakesh R <ra...@huawei.com>.


> On April 24, 2014, 12:19 p.m., Ivan Kelly wrote:
> > bookkeeper-server/src/main/proto/BookkeeperProtocol.proto, line 81
> > <https://reviews.apache.org/r/17895/diff/2/?file=563033#file563033line81>
> >
> >     ledgerId and entryId should be optional in all requests. It may be the case, that how we specify them changes in the future (like when we flatten the metadata), so it would be good to leave that possibility open.
> 
> Sijie Guo wrote:
>     for all existing reads/writes protocol, the ledgerId and entryId are required. I am not sure how u will change the protocol by flatten the metadata. but I guess that will be pretty new protocol. if so, it would be better to add new request type, so we will not break any existing systems or making it being complicated.
> 
> Ivan Kelly wrote:
>     Im not sure how it will change either. What I'm requesting is that the protobuf protocol doesnt lock us in to how we are doing it now forever.
> 
> Ivan Kelly wrote:
>     actually for a concrete example, lets say we want to do a read request for a whole ledger, from bookie A we request all entries, but it doesnt have every 3rd entry due to striping. In the case we can request all entrys from the ledger with entryid modulo 3 from bookie B. In this case, what would I put in the _required_ entry id firld for the read to bookie B?
> 
> Sijie Guo wrote:
>     as I said, doesn't it sound like a new read protocol?
> 
> Ivan Kelly wrote:
>     it will likely go through the same codepaths though, so we'll end up with a load of duplicate code. my concern with the requiredness of fields is that it's so rigid that in future we will have to add new messages to make any enhancements, causing the protocol to grow into something huge, with loads of redundancy, and not any better than we have now with the manual encoding.
> 
> Sijie Guo wrote:
>     single entry read/write are primitives of bookie, ledger id and entry id are required for them as they are the fundamental of bookkeeper. all other improvements like streaming or range read could be built on these primitives. then, if they are built on primitives, I don't see we will end up with a lot of duplicated codes.
> 
> Rakesh R wrote:
>     As far as compatibility issue is concerned, making optional is defensive approach and safe coding by avoiding parsing issues later. But it should be done very carefully at the code level because the requiredness is now handling at the code level. For example, at the server it should do validation to see a request has both ledgerId/entryId and which is mandatory or not etc. On the otherside for the required field, I could see the entity is not open for expansion by removing that field. But we have again options like like Sijie suggested, by defining new protocol and do the expansion.
>     
>     If we have a better way in hand to avoid code duplication, it is OK to go ahead with required.
> 
> Sijie Guo wrote:
>     as I said, currently bookie storage is built on single read/add entry primitives. there isn't any reason to make ledger id and entry id not to be required. if you are going to change the protocol to get rid of ledger id and entry id, you have to change the bookie storage. then I don't think there will be any code duplication.
> 
> Rakesh R wrote:
>     I agree this for add entry but while reading 'entryId' can be optional. There is no real functional issues, only the concern is this will force us to create new protocol if any such requirement comes in future.
> 
> Sijie Guo wrote:
>     again, as I said current bookie storage is per entry. if you want to support batch reads: 1) if you don't change bookie storage, you could build the batch read protocol on top of single read primitive. 2) if you changed bookie storage itself to support batch reads inside the storage, then it should be new request type to use new method in bookie storage, so the old read could still work with the storage that only support single read. this is for backward compatible.
> 
> Sijie Guo wrote:
>     one more comment, for any protocol requirements, please remember what kind of operations supported now in bookie storage, and what's the backward compatibility on bookie storage.

OK. makes sense to me.


- Rakesh


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/17895/#review41281
-----------------------------------------------------------


On April 24, 2014, 7:43 a.m., Sijie Guo wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/17895/
> -----------------------------------------------------------
> 
> (Updated April 24, 2014, 7:43 a.m.)
> 
> 
> Review request for bookkeeper and Ivan Kelly.
> 
> 
> Bugs: BOOKKEEPER-582
>     https://issues.apache.org/jira/browse/BOOKKEEPER-582
> 
> 
> Repository: bookkeeper-git
> 
> 
> Description
> -------
> 
> - introducing protobuf support for bookkeeper
> - for server: introduce packet processor / EnDecoder for different protocol supports
> - for client: change PCBC to use protobuf to send requests
> - misc changes for protobuf support
> 
> (bookie server is able for backward compatibility) 
> 
> 
> Diffs
> -----
> 
>   bookkeeper-server/pom.xml ebc1198 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/bookie/IndexInMemPageMgr.java 56487aa 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/LedgerChecker.java 28e23d6 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/PendingReadOp.java fb36b90 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/processor/RequestProcessor.java 241f369 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieProtoEncoding.java 1154047 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestHandler.java b922a82 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestProcessor.java 8155b22 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookkeeperProtocol.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBase.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBaseV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PerChannelBookieClient.java a10f7d5 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/proto/BookkeeperProtocol.proto PRE-CREATION 
>   bookkeeper-server/src/main/resources/findbugsExclude.xml 97a6156 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/proto/TestProtoVersions.java 5fcc445 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/replication/AuditorPeriodicCheckTest.java 3f8496f 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/BookieClientTest.java bc05229 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/TestBackwardCompat.java 8376b46 
>   compat-deps/bookkeeper-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/hedwig-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/pom.xml f79582d 
>   hedwig-server/pom.xml 06cf01c 
>   hedwig-server/src/test/java/org/apache/hedwig/server/TestBackwardCompat.java 8da109e 
> 
> Diff: https://reviews.apache.org/r/17895/diff/
> 
> 
> Testing
> -------
> 
> unit tests. backward tests.
> 
> 
> Thanks,
> 
> Sijie Guo
> 
>

Re: Review Request 17895: BOOKKEEPER-582: protobuf support for bookkeeper

Posted by Sijie Guo <gu...@gmail.com>.


> On April 24, 2014, 12:19 p.m., Ivan Kelly wrote:
> > bookkeeper-server/src/main/proto/BookkeeperProtocol.proto, line 81
> > <https://reviews.apache.org/r/17895/diff/2/?file=563033#file563033line81>
> >
> >     ledgerId and entryId should be optional in all requests. It may be the case, that how we specify them changes in the future (like when we flatten the metadata), so it would be good to leave that possibility open.
> 
> Sijie Guo wrote:
>     for all existing reads/writes protocol, the ledgerId and entryId are required. I am not sure how u will change the protocol by flatten the metadata. but I guess that will be pretty new protocol. if so, it would be better to add new request type, so we will not break any existing systems or making it being complicated.
> 
> Ivan Kelly wrote:
>     Im not sure how it will change either. What I'm requesting is that the protobuf protocol doesnt lock us in to how we are doing it now forever.
> 
> Ivan Kelly wrote:
>     actually for a concrete example, lets say we want to do a read request for a whole ledger, from bookie A we request all entries, but it doesnt have every 3rd entry due to striping. In the case we can request all entrys from the ledger with entryid modulo 3 from bookie B. In this case, what would I put in the _required_ entry id firld for the read to bookie B?
> 
> Sijie Guo wrote:
>     as I said, doesn't it sound like a new read protocol?
> 
> Ivan Kelly wrote:
>     it will likely go through the same codepaths though, so we'll end up with a load of duplicate code. my concern with the requiredness of fields is that it's so rigid that in future we will have to add new messages to make any enhancements, causing the protocol to grow into something huge, with loads of redundancy, and not any better than we have now with the manual encoding.
> 
> Sijie Guo wrote:
>     single entry read/write are primitives of bookie, ledger id and entry id are required for them as they are the fundamental of bookkeeper. all other improvements like streaming or range read could be built on these primitives. then, if they are built on primitives, I don't see we will end up with a lot of duplicated codes.
> 
> Rakesh R wrote:
>     As far as compatibility issue is concerned, making optional is defensive approach and safe coding by avoiding parsing issues later. But it should be done very carefully at the code level because the requiredness is now handling at the code level. For example, at the server it should do validation to see a request has both ledgerId/entryId and which is mandatory or not etc. On the otherside for the required field, I could see the entity is not open for expansion by removing that field. But we have again options like like Sijie suggested, by defining new protocol and do the expansion.
>     
>     If we have a better way in hand to avoid code duplication, it is OK to go ahead with required.
> 
> Sijie Guo wrote:
>     as I said, currently bookie storage is built on single read/add entry primitives. there isn't any reason to make ledger id and entry id not to be required. if you are going to change the protocol to get rid of ledger id and entry id, you have to change the bookie storage. then I don't think there will be any code duplication.
> 
> Rakesh R wrote:
>     I agree this for add entry but while reading 'entryId' can be optional. There is no real functional issues, only the concern is this will force us to create new protocol if any such requirement comes in future.
> 
> Sijie Guo wrote:
>     again, as I said current bookie storage is per entry. if you want to support batch reads: 1) if you don't change bookie storage, you could build the batch read protocol on top of single read primitive. 2) if you changed bookie storage itself to support batch reads inside the storage, then it should be new request type to use new method in bookie storage, so the old read could still work with the storage that only support single read. this is for backward compatible.

one more comment, for any protocol requirements, please remember what kind of operations supported now in bookie storage, and what's the backward compatibility on bookie storage. 


- Sijie


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/17895/#review41281
-----------------------------------------------------------


On April 24, 2014, 7:43 a.m., Sijie Guo wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/17895/
> -----------------------------------------------------------
> 
> (Updated April 24, 2014, 7:43 a.m.)
> 
> 
> Review request for bookkeeper and Ivan Kelly.
> 
> 
> Bugs: BOOKKEEPER-582
>     https://issues.apache.org/jira/browse/BOOKKEEPER-582
> 
> 
> Repository: bookkeeper-git
> 
> 
> Description
> -------
> 
> - introducing protobuf support for bookkeeper
> - for server: introduce packet processor / EnDecoder for different protocol supports
> - for client: change PCBC to use protobuf to send requests
> - misc changes for protobuf support
> 
> (bookie server is able for backward compatibility) 
> 
> 
> Diffs
> -----
> 
>   bookkeeper-server/pom.xml ebc1198 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/bookie/IndexInMemPageMgr.java 56487aa 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/LedgerChecker.java 28e23d6 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/PendingReadOp.java fb36b90 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/processor/RequestProcessor.java 241f369 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieProtoEncoding.java 1154047 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestHandler.java b922a82 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestProcessor.java 8155b22 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookkeeperProtocol.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBase.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBaseV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PerChannelBookieClient.java a10f7d5 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/proto/BookkeeperProtocol.proto PRE-CREATION 
>   bookkeeper-server/src/main/resources/findbugsExclude.xml 97a6156 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/proto/TestProtoVersions.java 5fcc445 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/replication/AuditorPeriodicCheckTest.java 3f8496f 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/BookieClientTest.java bc05229 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/TestBackwardCompat.java 8376b46 
>   compat-deps/bookkeeper-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/hedwig-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/pom.xml f79582d 
>   hedwig-server/pom.xml 06cf01c 
>   hedwig-server/src/test/java/org/apache/hedwig/server/TestBackwardCompat.java 8da109e 
> 
> Diff: https://reviews.apache.org/r/17895/diff/
> 
> 
> Testing
> -------
> 
> unit tests. backward tests.
> 
> 
> Thanks,
> 
> Sijie Guo
> 
>

Re: Review Request 17895: BOOKKEEPER-582: protobuf support for bookkeeper

Posted by Sijie Guo <gu...@gmail.com>.


> On April 24, 2014, 12:19 p.m., Ivan Kelly wrote:
> > bookkeeper-server/src/main/proto/BookkeeperProtocol.proto, line 81
> > <https://reviews.apache.org/r/17895/diff/2/?file=563033#file563033line81>
> >
> >     ledgerId and entryId should be optional in all requests. It may be the case, that how we specify them changes in the future (like when we flatten the metadata), so it would be good to leave that possibility open.
> 
> Sijie Guo wrote:
>     for all existing reads/writes protocol, the ledgerId and entryId are required. I am not sure how u will change the protocol by flatten the metadata. but I guess that will be pretty new protocol. if so, it would be better to add new request type, so we will not break any existing systems or making it being complicated.
> 
> Ivan Kelly wrote:
>     Im not sure how it will change either. What I'm requesting is that the protobuf protocol doesnt lock us in to how we are doing it now forever.
> 
> Ivan Kelly wrote:
>     actually for a concrete example, lets say we want to do a read request for a whole ledger, from bookie A we request all entries, but it doesnt have every 3rd entry due to striping. In the case we can request all entrys from the ledger with entryid modulo 3 from bookie B. In this case, what would I put in the _required_ entry id firld for the read to bookie B?
> 
> Sijie Guo wrote:
>     as I said, doesn't it sound like a new read protocol?
> 
> Ivan Kelly wrote:
>     it will likely go through the same codepaths though, so we'll end up with a load of duplicate code. my concern with the requiredness of fields is that it's so rigid that in future we will have to add new messages to make any enhancements, causing the protocol to grow into something huge, with loads of redundancy, and not any better than we have now with the manual encoding.

single entry read/write are primitives of bookie, ledger id and entry id are required for them as they are the fundamental of bookkeeper. all other improvements like streaming or range read could be built on these primitives. then, if they are built on primitives, I don't see we will end up with a lot of duplicated codes.  


- Sijie


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/17895/#review41281
-----------------------------------------------------------


On April 24, 2014, 7:43 a.m., Sijie Guo wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/17895/
> -----------------------------------------------------------
> 
> (Updated April 24, 2014, 7:43 a.m.)
> 
> 
> Review request for bookkeeper and Ivan Kelly.
> 
> 
> Bugs: BOOKKEEPER-582
>     https://issues.apache.org/jira/browse/BOOKKEEPER-582
> 
> 
> Repository: bookkeeper-git
> 
> 
> Description
> -------
> 
> - introducing protobuf support for bookkeeper
> - for server: introduce packet processor / EnDecoder for different protocol supports
> - for client: change PCBC to use protobuf to send requests
> - misc changes for protobuf support
> 
> (bookie server is able for backward compatibility) 
> 
> 
> Diffs
> -----
> 
>   bookkeeper-server/pom.xml ebc1198 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/bookie/IndexInMemPageMgr.java 56487aa 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/LedgerChecker.java 28e23d6 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/PendingReadOp.java fb36b90 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/processor/RequestProcessor.java 241f369 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieProtoEncoding.java 1154047 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestHandler.java b922a82 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestProcessor.java 8155b22 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookkeeperProtocol.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBase.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBaseV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PerChannelBookieClient.java a10f7d5 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/proto/BookkeeperProtocol.proto PRE-CREATION 
>   bookkeeper-server/src/main/resources/findbugsExclude.xml 97a6156 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/proto/TestProtoVersions.java 5fcc445 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/replication/AuditorPeriodicCheckTest.java 3f8496f 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/BookieClientTest.java bc05229 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/TestBackwardCompat.java 8376b46 
>   compat-deps/bookkeeper-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/hedwig-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/pom.xml f79582d 
>   hedwig-server/pom.xml 06cf01c 
>   hedwig-server/src/test/java/org/apache/hedwig/server/TestBackwardCompat.java 8da109e 
> 
> Diff: https://reviews.apache.org/r/17895/diff/
> 
> 
> Testing
> -------
> 
> unit tests. backward tests.
> 
> 
> Thanks,
> 
> Sijie Guo
> 
>

Re: Review Request 17895: BOOKKEEPER-582: protobuf support for bookkeeper

Posted by Rakesh R <ra...@huawei.com>.


> On April 24, 2014, 12:19 p.m., Ivan Kelly wrote:
> > bookkeeper-server/src/main/proto/BookkeeperProtocol.proto, line 81
> > <https://reviews.apache.org/r/17895/diff/2/?file=563033#file563033line81>
> >
> >     ledgerId and entryId should be optional in all requests. It may be the case, that how we specify them changes in the future (like when we flatten the metadata), so it would be good to leave that possibility open.
> 
> Sijie Guo wrote:
>     for all existing reads/writes protocol, the ledgerId and entryId are required. I am not sure how u will change the protocol by flatten the metadata. but I guess that will be pretty new protocol. if so, it would be better to add new request type, so we will not break any existing systems or making it being complicated.
> 
> Ivan Kelly wrote:
>     Im not sure how it will change either. What I'm requesting is that the protobuf protocol doesnt lock us in to how we are doing it now forever.
> 
> Ivan Kelly wrote:
>     actually for a concrete example, lets say we want to do a read request for a whole ledger, from bookie A we request all entries, but it doesnt have every 3rd entry due to striping. In the case we can request all entrys from the ledger with entryid modulo 3 from bookie B. In this case, what would I put in the _required_ entry id firld for the read to bookie B?
> 
> Sijie Guo wrote:
>     as I said, doesn't it sound like a new read protocol?
> 
> Ivan Kelly wrote:
>     it will likely go through the same codepaths though, so we'll end up with a load of duplicate code. my concern with the requiredness of fields is that it's so rigid that in future we will have to add new messages to make any enhancements, causing the protocol to grow into something huge, with loads of redundancy, and not any better than we have now with the manual encoding.
> 
> Sijie Guo wrote:
>     single entry read/write are primitives of bookie, ledger id and entry id are required for them as they are the fundamental of bookkeeper. all other improvements like streaming or range read could be built on these primitives. then, if they are built on primitives, I don't see we will end up with a lot of duplicated codes.
> 
> Rakesh R wrote:
>     As far as compatibility issue is concerned, making optional is defensive approach and safe coding by avoiding parsing issues later. But it should be done very carefully at the code level because the requiredness is now handling at the code level. For example, at the server it should do validation to see a request has both ledgerId/entryId and which is mandatory or not etc. On the otherside for the required field, I could see the entity is not open for expansion by removing that field. But we have again options like like Sijie suggested, by defining new protocol and do the expansion.
>     
>     If we have a better way in hand to avoid code duplication, it is OK to go ahead with required.
> 
> Sijie Guo wrote:
>     as I said, currently bookie storage is built on single read/add entry primitives. there isn't any reason to make ledger id and entry id not to be required. if you are going to change the protocol to get rid of ledger id and entry id, you have to change the bookie storage. then I don't think there will be any code duplication.

I agree this for add entry but while reading 'entryId' can be optional. There is no real functional issues, only the concern is this will force us to create new protocol if any such requirement comes in future.


- Rakesh


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/17895/#review41281
-----------------------------------------------------------


On April 24, 2014, 7:43 a.m., Sijie Guo wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/17895/
> -----------------------------------------------------------
> 
> (Updated April 24, 2014, 7:43 a.m.)
> 
> 
> Review request for bookkeeper and Ivan Kelly.
> 
> 
> Bugs: BOOKKEEPER-582
>     https://issues.apache.org/jira/browse/BOOKKEEPER-582
> 
> 
> Repository: bookkeeper-git
> 
> 
> Description
> -------
> 
> - introducing protobuf support for bookkeeper
> - for server: introduce packet processor / EnDecoder for different protocol supports
> - for client: change PCBC to use protobuf to send requests
> - misc changes for protobuf support
> 
> (bookie server is able for backward compatibility) 
> 
> 
> Diffs
> -----
> 
>   bookkeeper-server/pom.xml ebc1198 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/bookie/IndexInMemPageMgr.java 56487aa 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/LedgerChecker.java 28e23d6 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/PendingReadOp.java fb36b90 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/processor/RequestProcessor.java 241f369 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieProtoEncoding.java 1154047 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestHandler.java b922a82 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestProcessor.java 8155b22 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookkeeperProtocol.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBase.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBaseV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PerChannelBookieClient.java a10f7d5 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/proto/BookkeeperProtocol.proto PRE-CREATION 
>   bookkeeper-server/src/main/resources/findbugsExclude.xml 97a6156 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/proto/TestProtoVersions.java 5fcc445 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/replication/AuditorPeriodicCheckTest.java 3f8496f 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/BookieClientTest.java bc05229 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/TestBackwardCompat.java 8376b46 
>   compat-deps/bookkeeper-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/hedwig-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/pom.xml f79582d 
>   hedwig-server/pom.xml 06cf01c 
>   hedwig-server/src/test/java/org/apache/hedwig/server/TestBackwardCompat.java 8da109e 
> 
> Diff: https://reviews.apache.org/r/17895/diff/
> 
> 
> Testing
> -------
> 
> unit tests. backward tests.
> 
> 
> Thanks,
> 
> Sijie Guo
> 
>

Re: Review Request 17895: BOOKKEEPER-582: protobuf support for bookkeeper

Posted by Sijie Guo <gu...@gmail.com>.


> On April 24, 2014, 12:19 p.m., Ivan Kelly wrote:
> > bookkeeper-server/src/main/proto/BookkeeperProtocol.proto, line 81
> > <https://reviews.apache.org/r/17895/diff/2/?file=563033#file563033line81>
> >
> >     ledgerId and entryId should be optional in all requests. It may be the case, that how we specify them changes in the future (like when we flatten the metadata), so it would be good to leave that possibility open.

for all existing reads/writes protocol, the ledgerId and entryId are required. I am not sure how u will change the protocol by flatten the metadata. but I guess that will be pretty new protocol. if so, it would be better to add new request type, so we will not break any existing systems or making it being complicated.


- Sijie


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/17895/#review41281
-----------------------------------------------------------


On April 24, 2014, 7:43 a.m., Sijie Guo wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/17895/
> -----------------------------------------------------------
> 
> (Updated April 24, 2014, 7:43 a.m.)
> 
> 
> Review request for bookkeeper and Ivan Kelly.
> 
> 
> Bugs: BOOKKEEPER-582
>     https://issues.apache.org/jira/browse/BOOKKEEPER-582
> 
> 
> Repository: bookkeeper-git
> 
> 
> Description
> -------
> 
> - introducing protobuf support for bookkeeper
> - for server: introduce packet processor / EnDecoder for different protocol supports
> - for client: change PCBC to use protobuf to send requests
> - misc changes for protobuf support
> 
> (bookie server is able for backward compatibility) 
> 
> 
> Diffs
> -----
> 
>   bookkeeper-server/pom.xml ebc1198 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/bookie/IndexInMemPageMgr.java 56487aa 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/LedgerChecker.java 28e23d6 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/PendingReadOp.java fb36b90 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/processor/RequestProcessor.java 241f369 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieProtoEncoding.java 1154047 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestHandler.java b922a82 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestProcessor.java 8155b22 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookkeeperProtocol.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBase.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBaseV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PerChannelBookieClient.java a10f7d5 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/proto/BookkeeperProtocol.proto PRE-CREATION 
>   bookkeeper-server/src/main/resources/findbugsExclude.xml 97a6156 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/proto/TestProtoVersions.java 5fcc445 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/replication/AuditorPeriodicCheckTest.java 3f8496f 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/BookieClientTest.java bc05229 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/TestBackwardCompat.java 8376b46 
>   compat-deps/bookkeeper-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/hedwig-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/pom.xml f79582d 
>   hedwig-server/pom.xml 06cf01c 
>   hedwig-server/src/test/java/org/apache/hedwig/server/TestBackwardCompat.java 8da109e 
> 
> Diff: https://reviews.apache.org/r/17895/diff/
> 
> 
> Testing
> -------
> 
> unit tests. backward tests.
> 
> 
> Thanks,
> 
> Sijie Guo
> 
>

Re: Review Request 17895: BOOKKEEPER-582: protobuf support for bookkeeper

Posted by Ivan Kelly <iv...@apache.org>.


> On April 24, 2014, 12:19 p.m., Ivan Kelly wrote:
> > bookkeeper-server/src/main/proto/BookkeeperProtocol.proto, line 81
> > <https://reviews.apache.org/r/17895/diff/2/?file=563033#file563033line81>
> >
> >     ledgerId and entryId should be optional in all requests. It may be the case, that how we specify them changes in the future (like when we flatten the metadata), so it would be good to leave that possibility open.
> 
> Sijie Guo wrote:
>     for all existing reads/writes protocol, the ledgerId and entryId are required. I am not sure how u will change the protocol by flatten the metadata. but I guess that will be pretty new protocol. if so, it would be better to add new request type, so we will not break any existing systems or making it being complicated.
> 
> Ivan Kelly wrote:
>     Im not sure how it will change either. What I'm requesting is that the protobuf protocol doesnt lock us in to how we are doing it now forever.
> 
> Ivan Kelly wrote:
>     actually for a concrete example, lets say we want to do a read request for a whole ledger, from bookie A we request all entries, but it doesnt have every 3rd entry due to striping. In the case we can request all entrys from the ledger with entryid modulo 3 from bookie B. In this case, what would I put in the _required_ entry id firld for the read to bookie B?
> 
> Sijie Guo wrote:
>     as I said, doesn't it sound like a new read protocol?

it will likely go through the same codepaths though, so we'll end up with a load of duplicate code. my concern with the requiredness of fields is that it's so rigid that in future we will have to add new messages to make any enhancements, causing the protocol to grow into something huge, with loads of redundancy, and not any better than we have now with the manual encoding.


- Ivan


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/17895/#review41281
-----------------------------------------------------------


On April 24, 2014, 7:43 a.m., Sijie Guo wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/17895/
> -----------------------------------------------------------
> 
> (Updated April 24, 2014, 7:43 a.m.)
> 
> 
> Review request for bookkeeper and Ivan Kelly.
> 
> 
> Bugs: BOOKKEEPER-582
>     https://issues.apache.org/jira/browse/BOOKKEEPER-582
> 
> 
> Repository: bookkeeper-git
> 
> 
> Description
> -------
> 
> - introducing protobuf support for bookkeeper
> - for server: introduce packet processor / EnDecoder for different protocol supports
> - for client: change PCBC to use protobuf to send requests
> - misc changes for protobuf support
> 
> (bookie server is able for backward compatibility) 
> 
> 
> Diffs
> -----
> 
>   bookkeeper-server/pom.xml ebc1198 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/bookie/IndexInMemPageMgr.java 56487aa 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/LedgerChecker.java 28e23d6 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/PendingReadOp.java fb36b90 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/processor/RequestProcessor.java 241f369 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieProtoEncoding.java 1154047 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestHandler.java b922a82 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestProcessor.java 8155b22 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookkeeperProtocol.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBase.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBaseV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PerChannelBookieClient.java a10f7d5 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/proto/BookkeeperProtocol.proto PRE-CREATION 
>   bookkeeper-server/src/main/resources/findbugsExclude.xml 97a6156 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/proto/TestProtoVersions.java 5fcc445 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/replication/AuditorPeriodicCheckTest.java 3f8496f 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/BookieClientTest.java bc05229 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/TestBackwardCompat.java 8376b46 
>   compat-deps/bookkeeper-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/hedwig-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/pom.xml f79582d 
>   hedwig-server/pom.xml 06cf01c 
>   hedwig-server/src/test/java/org/apache/hedwig/server/TestBackwardCompat.java 8da109e 
> 
> Diff: https://reviews.apache.org/r/17895/diff/
> 
> 
> Testing
> -------
> 
> unit tests. backward tests.
> 
> 
> Thanks,
> 
> Sijie Guo
> 
>

Re: Review Request 17895: BOOKKEEPER-582: protobuf support for bookkeeper

Posted by Sijie Guo <gu...@gmail.com>.


> On April 24, 2014, 12:19 p.m., Ivan Kelly wrote:
> > bookkeeper-server/src/main/proto/BookkeeperProtocol.proto, line 81
> > <https://reviews.apache.org/r/17895/diff/2/?file=563033#file563033line81>
> >
> >     ledgerId and entryId should be optional in all requests. It may be the case, that how we specify them changes in the future (like when we flatten the metadata), so it would be good to leave that possibility open.
> 
> Sijie Guo wrote:
>     for all existing reads/writes protocol, the ledgerId and entryId are required. I am not sure how u will change the protocol by flatten the metadata. but I guess that will be pretty new protocol. if so, it would be better to add new request type, so we will not break any existing systems or making it being complicated.
> 
> Ivan Kelly wrote:
>     Im not sure how it will change either. What I'm requesting is that the protobuf protocol doesnt lock us in to how we are doing it now forever.
> 
> Ivan Kelly wrote:
>     actually for a concrete example, lets say we want to do a read request for a whole ledger, from bookie A we request all entries, but it doesnt have every 3rd entry due to striping. In the case we can request all entrys from the ledger with entryid modulo 3 from bookie B. In this case, what would I put in the _required_ entry id firld for the read to bookie B?
> 
> Sijie Guo wrote:
>     as I said, doesn't it sound like a new read protocol?
> 
> Ivan Kelly wrote:
>     it will likely go through the same codepaths though, so we'll end up with a load of duplicate code. my concern with the requiredness of fields is that it's so rigid that in future we will have to add new messages to make any enhancements, causing the protocol to grow into something huge, with loads of redundancy, and not any better than we have now with the manual encoding.
> 
> Sijie Guo wrote:
>     single entry read/write are primitives of bookie, ledger id and entry id are required for them as they are the fundamental of bookkeeper. all other improvements like streaming or range read could be built on these primitives. then, if they are built on primitives, I don't see we will end up with a lot of duplicated codes.
> 
> Rakesh R wrote:
>     As far as compatibility issue is concerned, making optional is defensive approach and safe coding by avoiding parsing issues later. But it should be done very carefully at the code level because the requiredness is now handling at the code level. For example, at the server it should do validation to see a request has both ledgerId/entryId and which is mandatory or not etc. On the otherside for the required field, I could see the entity is not open for expansion by removing that field. But we have again options like like Sijie suggested, by defining new protocol and do the expansion.
>     
>     If we have a better way in hand to avoid code duplication, it is OK to go ahead with required.

as I said, currently bookie storage is built on single read/add entry primitives. there isn't any reason to make ledger id and entry id not to be required. if you are going to change the protocol to get rid of ledger id and entry id, you have to change the bookie storage. then I don't think there will be any code duplication.


- Sijie


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/17895/#review41281
-----------------------------------------------------------


On April 24, 2014, 7:43 a.m., Sijie Guo wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/17895/
> -----------------------------------------------------------
> 
> (Updated April 24, 2014, 7:43 a.m.)
> 
> 
> Review request for bookkeeper and Ivan Kelly.
> 
> 
> Bugs: BOOKKEEPER-582
>     https://issues.apache.org/jira/browse/BOOKKEEPER-582
> 
> 
> Repository: bookkeeper-git
> 
> 
> Description
> -------
> 
> - introducing protobuf support for bookkeeper
> - for server: introduce packet processor / EnDecoder for different protocol supports
> - for client: change PCBC to use protobuf to send requests
> - misc changes for protobuf support
> 
> (bookie server is able for backward compatibility) 
> 
> 
> Diffs
> -----
> 
>   bookkeeper-server/pom.xml ebc1198 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/bookie/IndexInMemPageMgr.java 56487aa 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/LedgerChecker.java 28e23d6 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/PendingReadOp.java fb36b90 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/processor/RequestProcessor.java 241f369 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieProtoEncoding.java 1154047 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestHandler.java b922a82 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestProcessor.java 8155b22 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookkeeperProtocol.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBase.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBaseV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PerChannelBookieClient.java a10f7d5 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/proto/BookkeeperProtocol.proto PRE-CREATION 
>   bookkeeper-server/src/main/resources/findbugsExclude.xml 97a6156 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/proto/TestProtoVersions.java 5fcc445 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/replication/AuditorPeriodicCheckTest.java 3f8496f 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/BookieClientTest.java bc05229 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/TestBackwardCompat.java 8376b46 
>   compat-deps/bookkeeper-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/hedwig-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/pom.xml f79582d 
>   hedwig-server/pom.xml 06cf01c 
>   hedwig-server/src/test/java/org/apache/hedwig/server/TestBackwardCompat.java 8da109e 
> 
> Diff: https://reviews.apache.org/r/17895/diff/
> 
> 
> Testing
> -------
> 
> unit tests. backward tests.
> 
> 
> Thanks,
> 
> Sijie Guo
> 
>

Re: Review Request 17895: BOOKKEEPER-582: protobuf support for bookkeeper

Posted by Rakesh R <ra...@huawei.com>.


> On April 24, 2014, 12:19 p.m., Ivan Kelly wrote:
> > bookkeeper-server/src/main/proto/BookkeeperProtocol.proto, line 81
> > <https://reviews.apache.org/r/17895/diff/2/?file=563033#file563033line81>
> >
> >     ledgerId and entryId should be optional in all requests. It may be the case, that how we specify them changes in the future (like when we flatten the metadata), so it would be good to leave that possibility open.
> 
> Sijie Guo wrote:
>     for all existing reads/writes protocol, the ledgerId and entryId are required. I am not sure how u will change the protocol by flatten the metadata. but I guess that will be pretty new protocol. if so, it would be better to add new request type, so we will not break any existing systems or making it being complicated.
> 
> Ivan Kelly wrote:
>     Im not sure how it will change either. What I'm requesting is that the protobuf protocol doesnt lock us in to how we are doing it now forever.
> 
> Ivan Kelly wrote:
>     actually for a concrete example, lets say we want to do a read request for a whole ledger, from bookie A we request all entries, but it doesnt have every 3rd entry due to striping. In the case we can request all entrys from the ledger with entryid modulo 3 from bookie B. In this case, what would I put in the _required_ entry id firld for the read to bookie B?
> 
> Sijie Guo wrote:
>     as I said, doesn't it sound like a new read protocol?
> 
> Ivan Kelly wrote:
>     it will likely go through the same codepaths though, so we'll end up with a load of duplicate code. my concern with the requiredness of fields is that it's so rigid that in future we will have to add new messages to make any enhancements, causing the protocol to grow into something huge, with loads of redundancy, and not any better than we have now with the manual encoding.
> 
> Sijie Guo wrote:
>     single entry read/write are primitives of bookie, ledger id and entry id are required for them as they are the fundamental of bookkeeper. all other improvements like streaming or range read could be built on these primitives. then, if they are built on primitives, I don't see we will end up with a lot of duplicated codes.

As far as compatibility issue is concerned, making optional is defensive approach and safe coding by avoiding parsing issues later. But it should be done very carefully at the code level because the requiredness is now handling at the code level. For example, at the server it should do validation to see a request has both ledgerId/entryId and which is mandatory or not etc. On the otherside for the required field, I could see the entity is not open for expansion by removing that field. But we have again options like like Sijie suggested, by defining new protocol and do the expansion.

If we have a better way in hand to avoid code duplication, it is OK to go ahead with required.


- Rakesh


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/17895/#review41281
-----------------------------------------------------------


On April 24, 2014, 7:43 a.m., Sijie Guo wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/17895/
> -----------------------------------------------------------
> 
> (Updated April 24, 2014, 7:43 a.m.)
> 
> 
> Review request for bookkeeper and Ivan Kelly.
> 
> 
> Bugs: BOOKKEEPER-582
>     https://issues.apache.org/jira/browse/BOOKKEEPER-582
> 
> 
> Repository: bookkeeper-git
> 
> 
> Description
> -------
> 
> - introducing protobuf support for bookkeeper
> - for server: introduce packet processor / EnDecoder for different protocol supports
> - for client: change PCBC to use protobuf to send requests
> - misc changes for protobuf support
> 
> (bookie server is able for backward compatibility) 
> 
> 
> Diffs
> -----
> 
>   bookkeeper-server/pom.xml ebc1198 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/bookie/IndexInMemPageMgr.java 56487aa 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/LedgerChecker.java 28e23d6 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/PendingReadOp.java fb36b90 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/processor/RequestProcessor.java 241f369 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieProtoEncoding.java 1154047 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestHandler.java b922a82 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestProcessor.java 8155b22 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookkeeperProtocol.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBase.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBaseV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PerChannelBookieClient.java a10f7d5 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/proto/BookkeeperProtocol.proto PRE-CREATION 
>   bookkeeper-server/src/main/resources/findbugsExclude.xml 97a6156 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/proto/TestProtoVersions.java 5fcc445 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/replication/AuditorPeriodicCheckTest.java 3f8496f 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/BookieClientTest.java bc05229 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/TestBackwardCompat.java 8376b46 
>   compat-deps/bookkeeper-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/hedwig-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/pom.xml f79582d 
>   hedwig-server/pom.xml 06cf01c 
>   hedwig-server/src/test/java/org/apache/hedwig/server/TestBackwardCompat.java 8da109e 
> 
> Diff: https://reviews.apache.org/r/17895/diff/
> 
> 
> Testing
> -------
> 
> unit tests. backward tests.
> 
> 
> Thanks,
> 
> Sijie Guo
> 
>

Re: Review Request 17895: BOOKKEEPER-582: protobuf support for bookkeeper

Posted by Ivan Kelly <iv...@apache.org>.


> On April 24, 2014, 12:19 p.m., Ivan Kelly wrote:
> > bookkeeper-server/src/main/proto/BookkeeperProtocol.proto, line 81
> > <https://reviews.apache.org/r/17895/diff/2/?file=563033#file563033line81>
> >
> >     ledgerId and entryId should be optional in all requests. It may be the case, that how we specify them changes in the future (like when we flatten the metadata), so it would be good to leave that possibility open.
> 
> Sijie Guo wrote:
>     for all existing reads/writes protocol, the ledgerId and entryId are required. I am not sure how u will change the protocol by flatten the metadata. but I guess that will be pretty new protocol. if so, it would be better to add new request type, so we will not break any existing systems or making it being complicated.
> 
> Ivan Kelly wrote:
>     Im not sure how it will change either. What I'm requesting is that the protobuf protocol doesnt lock us in to how we are doing it now forever.

actually for a concrete example, lets say we want to do a read request for a whole ledger, from bookie A we request all entries, but it doesnt have every 3rd entry due to striping. In the case we can request all entrys from the ledger with entryid modulo 3 from bookie B. In this case, what would I put in the _required_ entry id firld for the read to bookie B?


- Ivan


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/17895/#review41281
-----------------------------------------------------------


On April 24, 2014, 7:43 a.m., Sijie Guo wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/17895/
> -----------------------------------------------------------
> 
> (Updated April 24, 2014, 7:43 a.m.)
> 
> 
> Review request for bookkeeper and Ivan Kelly.
> 
> 
> Bugs: BOOKKEEPER-582
>     https://issues.apache.org/jira/browse/BOOKKEEPER-582
> 
> 
> Repository: bookkeeper-git
> 
> 
> Description
> -------
> 
> - introducing protobuf support for bookkeeper
> - for server: introduce packet processor / EnDecoder for different protocol supports
> - for client: change PCBC to use protobuf to send requests
> - misc changes for protobuf support
> 
> (bookie server is able for backward compatibility) 
> 
> 
> Diffs
> -----
> 
>   bookkeeper-server/pom.xml ebc1198 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/bookie/IndexInMemPageMgr.java 56487aa 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/LedgerChecker.java 28e23d6 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/PendingReadOp.java fb36b90 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/processor/RequestProcessor.java 241f369 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieProtoEncoding.java 1154047 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestHandler.java b922a82 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestProcessor.java 8155b22 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookkeeperProtocol.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBase.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBaseV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PerChannelBookieClient.java a10f7d5 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/proto/BookkeeperProtocol.proto PRE-CREATION 
>   bookkeeper-server/src/main/resources/findbugsExclude.xml 97a6156 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/proto/TestProtoVersions.java 5fcc445 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/replication/AuditorPeriodicCheckTest.java 3f8496f 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/BookieClientTest.java bc05229 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/TestBackwardCompat.java 8376b46 
>   compat-deps/bookkeeper-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/hedwig-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/pom.xml f79582d 
>   hedwig-server/pom.xml 06cf01c 
>   hedwig-server/src/test/java/org/apache/hedwig/server/TestBackwardCompat.java 8da109e 
> 
> Diff: https://reviews.apache.org/r/17895/diff/
> 
> 
> Testing
> -------
> 
> unit tests. backward tests.
> 
> 
> Thanks,
> 
> Sijie Guo
> 
>

Re: Review Request 17895: BOOKKEEPER-582: protobuf support for bookkeeper

Posted by Sijie Guo <gu...@gmail.com>.


> On April 24, 2014, 12:19 p.m., Ivan Kelly wrote:
> > bookkeeper-server/src/main/proto/BookkeeperProtocol.proto, line 81
> > <https://reviews.apache.org/r/17895/diff/2/?file=563033#file563033line81>
> >
> >     ledgerId and entryId should be optional in all requests. It may be the case, that how we specify them changes in the future (like when we flatten the metadata), so it would be good to leave that possibility open.
> 
> Sijie Guo wrote:
>     for all existing reads/writes protocol, the ledgerId and entryId are required. I am not sure how u will change the protocol by flatten the metadata. but I guess that will be pretty new protocol. if so, it would be better to add new request type, so we will not break any existing systems or making it being complicated.
> 
> Ivan Kelly wrote:
>     Im not sure how it will change either. What I'm requesting is that the protobuf protocol doesnt lock us in to how we are doing it now forever.
> 
> Ivan Kelly wrote:
>     actually for a concrete example, lets say we want to do a read request for a whole ledger, from bookie A we request all entries, but it doesnt have every 3rd entry due to striping. In the case we can request all entrys from the ledger with entryid modulo 3 from bookie B. In this case, what would I put in the _required_ entry id firld for the read to bookie B?
> 
> Sijie Guo wrote:
>     as I said, doesn't it sound like a new read protocol?
> 
> Ivan Kelly wrote:
>     it will likely go through the same codepaths though, so we'll end up with a load of duplicate code. my concern with the requiredness of fields is that it's so rigid that in future we will have to add new messages to make any enhancements, causing the protocol to grow into something huge, with loads of redundancy, and not any better than we have now with the manual encoding.
> 
> Sijie Guo wrote:
>     single entry read/write are primitives of bookie, ledger id and entry id are required for them as they are the fundamental of bookkeeper. all other improvements like streaming or range read could be built on these primitives. then, if they are built on primitives, I don't see we will end up with a lot of duplicated codes.
> 
> Rakesh R wrote:
>     As far as compatibility issue is concerned, making optional is defensive approach and safe coding by avoiding parsing issues later. But it should be done very carefully at the code level because the requiredness is now handling at the code level. For example, at the server it should do validation to see a request has both ledgerId/entryId and which is mandatory or not etc. On the otherside for the required field, I could see the entity is not open for expansion by removing that field. But we have again options like like Sijie suggested, by defining new protocol and do the expansion.
>     
>     If we have a better way in hand to avoid code duplication, it is OK to go ahead with required.
> 
> Sijie Guo wrote:
>     as I said, currently bookie storage is built on single read/add entry primitives. there isn't any reason to make ledger id and entry id not to be required. if you are going to change the protocol to get rid of ledger id and entry id, you have to change the bookie storage. then I don't think there will be any code duplication.
> 
> Rakesh R wrote:
>     I agree this for add entry but while reading 'entryId' can be optional. There is no real functional issues, only the concern is this will force us to create new protocol if any such requirement comes in future.

again, as I said current bookie storage is per entry. if you want to support batch reads: 1) if you don't change bookie storage, you could build the batch read protocol on top of single read primitive. 2) if you changed bookie storage itself to support batch reads inside the storage, then it should be new request type to use new method in bookie storage, so the old read could still work with the storage that only support single read. this is for backward compatible. 


- Sijie


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/17895/#review41281
-----------------------------------------------------------


On April 24, 2014, 7:43 a.m., Sijie Guo wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/17895/
> -----------------------------------------------------------
> 
> (Updated April 24, 2014, 7:43 a.m.)
> 
> 
> Review request for bookkeeper and Ivan Kelly.
> 
> 
> Bugs: BOOKKEEPER-582
>     https://issues.apache.org/jira/browse/BOOKKEEPER-582
> 
> 
> Repository: bookkeeper-git
> 
> 
> Description
> -------
> 
> - introducing protobuf support for bookkeeper
> - for server: introduce packet processor / EnDecoder for different protocol supports
> - for client: change PCBC to use protobuf to send requests
> - misc changes for protobuf support
> 
> (bookie server is able for backward compatibility) 
> 
> 
> Diffs
> -----
> 
>   bookkeeper-server/pom.xml ebc1198 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/bookie/IndexInMemPageMgr.java 56487aa 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/LedgerChecker.java 28e23d6 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/PendingReadOp.java fb36b90 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/processor/RequestProcessor.java 241f369 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieProtoEncoding.java 1154047 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestHandler.java b922a82 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestProcessor.java 8155b22 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookkeeperProtocol.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBase.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBaseV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PerChannelBookieClient.java a10f7d5 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/proto/BookkeeperProtocol.proto PRE-CREATION 
>   bookkeeper-server/src/main/resources/findbugsExclude.xml 97a6156 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/proto/TestProtoVersions.java 5fcc445 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/replication/AuditorPeriodicCheckTest.java 3f8496f 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/BookieClientTest.java bc05229 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/TestBackwardCompat.java 8376b46 
>   compat-deps/bookkeeper-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/hedwig-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/pom.xml f79582d 
>   hedwig-server/pom.xml 06cf01c 
>   hedwig-server/src/test/java/org/apache/hedwig/server/TestBackwardCompat.java 8da109e 
> 
> Diff: https://reviews.apache.org/r/17895/diff/
> 
> 
> Testing
> -------
> 
> unit tests. backward tests.
> 
> 
> Thanks,
> 
> Sijie Guo
> 
>

Re: Review Request 17895: BOOKKEEPER-582: protobuf support for bookkeeper

Posted by Ivan Kelly <iv...@apache.org>.

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/17895/#review41281
-----------------------------------------------------------



bookkeeper-server/src/main/proto/BookkeeperProtocol.proto
<https://reviews.apache.org/r/17895/#comment74718>

    ledgerId and entryId should be optional in all requests. It may be the case, that how we specify them changes in the future (like when we flatten the metadata), so it would be good to leave that possibility open.


- Ivan Kelly


On April 24, 2014, 7:43 a.m., Sijie Guo wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/17895/
> -----------------------------------------------------------
> 
> (Updated April 24, 2014, 7:43 a.m.)
> 
> 
> Review request for bookkeeper and Ivan Kelly.
> 
> 
> Bugs: BOOKKEEPER-582
>     https://issues.apache.org/jira/browse/BOOKKEEPER-582
> 
> 
> Repository: bookkeeper-git
> 
> 
> Description
> -------
> 
> - introducing protobuf support for bookkeeper
> - for server: introduce packet processor / EnDecoder for different protocol supports
> - for client: change PCBC to use protobuf to send requests
> - misc changes for protobuf support
> 
> (bookie server is able for backward compatibility) 
> 
> 
> Diffs
> -----
> 
>   bookkeeper-server/pom.xml ebc1198 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/bookie/IndexInMemPageMgr.java 56487aa 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/LedgerChecker.java 28e23d6 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/PendingReadOp.java fb36b90 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/processor/RequestProcessor.java 241f369 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieProtoEncoding.java 1154047 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestHandler.java b922a82 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestProcessor.java 8155b22 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookkeeperProtocol.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBase.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBaseV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PerChannelBookieClient.java a10f7d5 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/proto/BookkeeperProtocol.proto PRE-CREATION 
>   bookkeeper-server/src/main/resources/findbugsExclude.xml 97a6156 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/proto/TestProtoVersions.java 5fcc445 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/replication/AuditorPeriodicCheckTest.java 3f8496f 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/BookieClientTest.java bc05229 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/TestBackwardCompat.java 8376b46 
>   compat-deps/bookkeeper-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/hedwig-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/pom.xml f79582d 
>   hedwig-server/pom.xml 06cf01c 
>   hedwig-server/src/test/java/org/apache/hedwig/server/TestBackwardCompat.java 8da109e 
> 
> Diff: https://reviews.apache.org/r/17895/diff/
> 
> 
> Testing
> -------
> 
> unit tests. backward tests.
> 
> 
> Thanks,
> 
> Sijie Guo
> 
>

Re: Review Request 17895: BOOKKEEPER-582: protobuf support for bookkeeper

Posted by Sijie Guo <gu...@gmail.com>.

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/17895/#review43940
-----------------------------------------------------------


just a ping to @fpj and @Rakesh

- Sijie Guo


On April 24, 2014, 7:43 a.m., Sijie Guo wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/17895/
> -----------------------------------------------------------
> 
> (Updated April 24, 2014, 7:43 a.m.)
> 
> 
> Review request for bookkeeper and Ivan Kelly.
> 
> 
> Bugs: BOOKKEEPER-582
>     https://issues.apache.org/jira/browse/BOOKKEEPER-582
> 
> 
> Repository: bookkeeper-git
> 
> 
> Description
> -------
> 
> - introducing protobuf support for bookkeeper
> - for server: introduce packet processor / EnDecoder for different protocol supports
> - for client: change PCBC to use protobuf to send requests
> - misc changes for protobuf support
> 
> (bookie server is able for backward compatibility) 
> 
> 
> Diffs
> -----
> 
>   bookkeeper-server/pom.xml ebc1198 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/bookie/IndexInMemPageMgr.java 56487aa 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/LedgerChecker.java 28e23d6 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/PendingReadOp.java fb36b90 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/processor/RequestProcessor.java 241f369 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieProtoEncoding.java 1154047 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestHandler.java b922a82 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestProcessor.java 8155b22 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookkeeperProtocol.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBase.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBaseV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PerChannelBookieClient.java a10f7d5 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/proto/BookkeeperProtocol.proto PRE-CREATION 
>   bookkeeper-server/src/main/resources/findbugsExclude.xml 97a6156 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/proto/TestProtoVersions.java 5fcc445 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/replication/AuditorPeriodicCheckTest.java 3f8496f 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/BookieClientTest.java bc05229 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/TestBackwardCompat.java 8376b46 
>   compat-deps/bookkeeper-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/hedwig-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/pom.xml f79582d 
>   hedwig-server/pom.xml 06cf01c 
>   hedwig-server/src/test/java/org/apache/hedwig/server/TestBackwardCompat.java 8da109e 
> 
> Diff: https://reviews.apache.org/r/17895/diff/
> 
> 
> Testing
> -------
> 
> unit tests. backward tests.
> 
> 
> Thanks,
> 
> Sijie Guo
> 
>

Re: Review Request 17895: BOOKKEEPER-582: protobuf support for bookkeeper

Posted by Sijie Guo <gu...@gmail.com>.

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/17895/
-----------------------------------------------------------

(Updated April 24, 2014, 7:43 a.m.)


Review request for bookkeeper and Ivan Kelly.


Bugs: BOOKKEEPER-582
    https://issues.apache.org/jira/browse/BOOKKEEPER-582


Repository: bookkeeper-git


Description
-------

- introducing protobuf support for bookkeeper
- for server: introduce packet processor / EnDecoder for different protocol supports
- for client: change PCBC to use protobuf to send requests
- misc changes for protobuf support

(bookie server is able for backward compatibility) 


Diffs (updated)
-----

  bookkeeper-server/pom.xml ebc1198 
  bookkeeper-server/src/main/java/org/apache/bookkeeper/bookie/IndexInMemPageMgr.java 56487aa 
  bookkeeper-server/src/main/java/org/apache/bookkeeper/client/LedgerChecker.java 28e23d6 
  bookkeeper-server/src/main/java/org/apache/bookkeeper/client/PendingReadOp.java fb36b90 
  bookkeeper-server/src/main/java/org/apache/bookkeeper/processor/RequestProcessor.java 241f369 
  bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieProtoEncoding.java 1154047 
  bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestHandler.java b922a82 
  bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestProcessor.java 8155b22 
  bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookkeeperProtocol.java PRE-CREATION 
  bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBase.java PRE-CREATION 
  bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBaseV3.java PRE-CREATION 
  bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PerChannelBookieClient.java a10f7d5 
  bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessor.java PRE-CREATION 
  bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessorV3.java PRE-CREATION 
  bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessor.java PRE-CREATION 
  bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessorV3.java PRE-CREATION 
  bookkeeper-server/src/main/proto/BookkeeperProtocol.proto PRE-CREATION 
  bookkeeper-server/src/main/resources/findbugsExclude.xml 97a6156 
  bookkeeper-server/src/test/java/org/apache/bookkeeper/proto/TestProtoVersions.java 5fcc445 
  bookkeeper-server/src/test/java/org/apache/bookkeeper/replication/AuditorPeriodicCheckTest.java 3f8496f 
  bookkeeper-server/src/test/java/org/apache/bookkeeper/test/BookieClientTest.java bc05229 
  bookkeeper-server/src/test/java/org/apache/bookkeeper/test/TestBackwardCompat.java 8376b46 
  compat-deps/bookkeeper-server-compat-4.2.0/pom.xml PRE-CREATION 
  compat-deps/hedwig-server-compat-4.2.0/pom.xml PRE-CREATION 
  compat-deps/pom.xml f79582d 
  hedwig-server/pom.xml 06cf01c 
  hedwig-server/src/test/java/org/apache/hedwig/server/TestBackwardCompat.java 8da109e 

Diff: https://reviews.apache.org/r/17895/diff/


Testing
-------

unit tests. backward tests.


Thanks,

Sijie Guo

Re: Review Request 17895: BOOKKEEPER-582: protobuf support for bookkeeper

Posted by Ivan Kelly <iv...@apache.org>.


> On April 23, 2014, 10:22 a.m., Ivan Kelly wrote:
> >
> 
> Sijie Guo wrote:
>     ok. let me step back. how bad is the current protocol? if no, why we keep arguing on this? as those changes will break our system, then I don't see the value of contributing our patches back to the community.

For me, the motivating change was auth. The initial drop I did for auth[1] was based in PB to allow for auth providers to include their own extensions with PB and not have to deal with parsing. This was mixing old parsing and PB though, so I held off the change until PB went in, so that we wouldnt have two parsing mechanisms being actively developed.

For me, this motivation is still valid. Having two decoding mechanisms is ugly and hacky. With the plan to add batch reads,it also makes sense to be easily able to add messages.

Another motivation is to reduce the variation between the branches. We currently have 3 branchs, the apache branch, the twitter branch and the yahoo branch (perhaps huawei also have a branch). These will unlikely ever be 100% identical, but I had hoped that we could keep the difference to a minimum to allow for us to be able to benefit from each others changes.

That said, changes from all sides need to go through the full review process before going in. Both companies have different production usecases, roadmaps, and rollout mechanisms, so assumptions may not hold across organisations.

To bring it back to the current patch, and your initial question, the current protocol isn't terrible. The code for it is a hell of a lot cleaner than it was 2 years ago. However, it's cumbersome to add anything to the protocol, mostly because of decisions taken early on, (such as the difference in position of ledgerid and entryid in read and add requests). I was hoping we could avoid locking ourselves into something like this again. 

[1] https://github.com/ivankelly/bookkeeper/commits/BookKeeperAuth 


- Ivan


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/17895/#review41130
-----------------------------------------------------------


On April 24, 2014, 7:43 a.m., Sijie Guo wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/17895/
> -----------------------------------------------------------
> 
> (Updated April 24, 2014, 7:43 a.m.)
> 
> 
> Review request for bookkeeper and Ivan Kelly.
> 
> 
> Bugs: BOOKKEEPER-582
>     https://issues.apache.org/jira/browse/BOOKKEEPER-582
> 
> 
> Repository: bookkeeper-git
> 
> 
> Description
> -------
> 
> - introducing protobuf support for bookkeeper
> - for server: introduce packet processor / EnDecoder for different protocol supports
> - for client: change PCBC to use protobuf to send requests
> - misc changes for protobuf support
> 
> (bookie server is able for backward compatibility) 
> 
> 
> Diffs
> -----
> 
>   bookkeeper-server/pom.xml ebc1198 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/bookie/IndexInMemPageMgr.java 56487aa 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/LedgerChecker.java 28e23d6 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/PendingReadOp.java fb36b90 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/processor/RequestProcessor.java 241f369 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieProtoEncoding.java 1154047 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestHandler.java b922a82 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestProcessor.java 8155b22 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookkeeperProtocol.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBase.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBaseV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PerChannelBookieClient.java a10f7d5 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/proto/BookkeeperProtocol.proto PRE-CREATION 
>   bookkeeper-server/src/main/resources/findbugsExclude.xml 97a6156 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/proto/TestProtoVersions.java 5fcc445 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/replication/AuditorPeriodicCheckTest.java 3f8496f 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/BookieClientTest.java bc05229 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/TestBackwardCompat.java 8376b46 
>   compat-deps/bookkeeper-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/hedwig-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/pom.xml f79582d 
>   hedwig-server/pom.xml 06cf01c 
>   hedwig-server/src/test/java/org/apache/hedwig/server/TestBackwardCompat.java 8da109e 
> 
> Diff: https://reviews.apache.org/r/17895/diff/
> 
> 
> Testing
> -------
> 
> unit tests. backward tests.
> 
> 
> Thanks,
> 
> Sijie Guo
> 
>

Re: Review Request 17895: BOOKKEEPER-582: protobuf support for bookkeeper

Posted by Ivan Kelly <iv...@apache.org>.


> On April 23, 2014, 10:22 a.m., Ivan Kelly wrote:
> > bookkeeper-server/src/main/proto/BookkeeperProtocol.proto, line 80
> > <https://reviews.apache.org/r/17895/diff/2/?file=563033#file563033line80>
> >
> >     This would be better served with a boolean. protobuf will keep it compact.
> 
> Sijie Guo wrote:
>     being Flag will make it easier to add other flags in future.

No it doesn't. Lets say you do add another flag in the future. How do you specify that it's both a FENCE_LEDGER and NEW_FLAG? You need the field to be repeated, and then you need code to loop through the flags. Compared to msg.isFenceLedger(), this seems much more cumbersome.


> On April 23, 2014, 10:22 a.m., Ivan Kelly wrote:
> > bookkeeper-server/src/main/proto/BookkeeperProtocol.proto, line 65
> > <https://reviews.apache.org/r/17895/diff/2/?file=563033#file563033line65>
> >
> >     Comment 1.
> >     OperationType is redundant. The server can do #hasReadRequest and #hasAddRequest to check the request to check the type. We shouldn't send redundant data over the wire where possible.
> >     
> >     Comment 2.
> >     it better to make the absolute minimum to be required. Required is forever, and these may not be.
> >     
> >     https://developers.google.com/protocol-buffers/docs/proto
> >
> 
> Sijie Guo wrote:
>     > comment 1.
>     
>     OperationType will make request more clear and specify and less if...else branches. And OperationType is used for PCBC to unify all requests handling. so we don't need to have individual maps to maintain requests each time we added a new type of requests.
>     
>     > comment 2.
>     
>     if reply to comment 1 works for u, I don't see any reason why operation would not be a required.

Ok. I can live with it, though I still think it's a little cumbersome. Regarding requiredness, I still think it should be optional. All fields should be optional by default to give you as much freedom to evolve the protocol in the future as possible. Especially something, which is not 100% essential to the protocol, like this field.


> On April 23, 2014, 10:22 a.m., Ivan Kelly wrote:
> > bookkeeper-server/src/main/proto/BookkeeperProtocol.proto, line 33
> > <https://reviews.apache.org/r/17895/diff/2/?file=563033#file563033line33>
> >
> >     This should certainly not be an enum. Otherwise we need to bump the protocol version each time we add an error code.
> >     
> >     Imagine the scenario where both server and client are running 4.3.0. Then the server is upgraded with 4.3.1 which a new error EPRINTERONFIRE. It sends this to the client who throws a decode error.
> 
> Sijie Guo wrote:
>     how could being not enum help this? if it is integer, client still has no idea how to interpret, so it is still invalid response from 4.3.0 client. I thought we reached an agreement on enum on the ticket, no?

So for version and operationtype, enum is ok. These originate at the client, so if the servers are always upgraded at the client, there's no interoperability issues. Status codes originate at the server though, so it is possible for the server to send a statuscode that is unrecognised to a client. The normal way to handle this would be a "else" or "default:" to pass this up to the client as a BKException.UnexpectedConditionException. If it's an enum, this will throw a decode exception in the netty decoder, which is harder to handle.

To resolve this on the server side, by checking the version and only sending errors valid for that version, implies two things. Firstly, every error code change will require the version to be bumped and secondly, that there will need to be a list maintained for which errors are valid for each version. This goes against the motivation for using protobuf in the first place.


> On April 23, 2014, 10:22 a.m., Ivan Kelly wrote:
> > bookkeeper-server/src/main/proto/BookkeeperProtocol.proto, line 104
> > <https://reviews.apache.org/r/17895/diff/2/?file=563033#file563033line104>
> >
> >     You're sending StatusCode twice, every time. Firstly, shouldn't be an enum as stated above. Secondly, shouldn't be required.
> 
> Sijie Guo wrote:
>     > enum
>     
>     as the comments above.
>     
>     > status code twice.
>     
>     the status code for ReadResponse/AddResponse is for individual responses. if we are going to support kind of batch reads, the status code of Response means either the whole batch succeed or not while the individual read responses might have different status codes (e.g OK or NotExists). That is why it exists two places.
>     
>     > required
>     
>     as the comments above

Per request makes sense. However, in that case, can't you just remove the per packet status?


- Ivan


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/17895/#review41130
-----------------------------------------------------------


On April 24, 2014, 7:43 a.m., Sijie Guo wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/17895/
> -----------------------------------------------------------
> 
> (Updated April 24, 2014, 7:43 a.m.)
> 
> 
> Review request for bookkeeper and Ivan Kelly.
> 
> 
> Bugs: BOOKKEEPER-582
>     https://issues.apache.org/jira/browse/BOOKKEEPER-582
> 
> 
> Repository: bookkeeper-git
> 
> 
> Description
> -------
> 
> - introducing protobuf support for bookkeeper
> - for server: introduce packet processor / EnDecoder for different protocol supports
> - for client: change PCBC to use protobuf to send requests
> - misc changes for protobuf support
> 
> (bookie server is able for backward compatibility) 
> 
> 
> Diffs
> -----
> 
>   bookkeeper-server/pom.xml ebc1198 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/bookie/IndexInMemPageMgr.java 56487aa 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/LedgerChecker.java 28e23d6 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/PendingReadOp.java fb36b90 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/processor/RequestProcessor.java 241f369 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieProtoEncoding.java 1154047 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestHandler.java b922a82 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestProcessor.java 8155b22 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookkeeperProtocol.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBase.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBaseV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PerChannelBookieClient.java a10f7d5 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/proto/BookkeeperProtocol.proto PRE-CREATION 
>   bookkeeper-server/src/main/resources/findbugsExclude.xml 97a6156 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/proto/TestProtoVersions.java 5fcc445 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/replication/AuditorPeriodicCheckTest.java 3f8496f 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/BookieClientTest.java bc05229 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/TestBackwardCompat.java 8376b46 
>   compat-deps/bookkeeper-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/hedwig-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/pom.xml f79582d 
>   hedwig-server/pom.xml 06cf01c 
>   hedwig-server/src/test/java/org/apache/hedwig/server/TestBackwardCompat.java 8da109e 
> 
> Diff: https://reviews.apache.org/r/17895/diff/
> 
> 
> Testing
> -------
> 
> unit tests. backward tests.
> 
> 
> Thanks,
> 
> Sijie Guo
> 
>

Re: Review Request 17895: BOOKKEEPER-582: protobuf support for bookkeeper

Posted by Sijie Guo <gu...@gmail.com>.

On Tue, May 27, 2014 at 11:52 PM, Rakesh R <ra...@huawei.com> wrote:

>
>
> > On April 23, 2014, 10:22 a.m., Ivan Kelly wrote:
> > > bookkeeper-server/src/main/proto/BookkeeperProtocol.proto, line 80
> > > <
> https://reviews.apache.org/r/17895/diff/2/?file=563033#file563033line80>
> > >
> > >     This would be better served with a boolean. protobuf will keep it
> compact.
> >
> > Sijie Guo wrote:
> >     being Flag will make it easier to add other flags in future.
> >
> > Ivan Kelly wrote:
> >     No it doesn't. Lets say you do add another flag in the future. How
> do you specify that it's both a FENCE_LEDGER and NEW_FLAG? You need the
> field to be repeated, and then you need code to loop through the flags.
> Compared to msg.isFenceLedger(), this seems much more cumbersome.
> >
> > Sijie Guo wrote:
> >     I don't say this field is bits-set-like of flags. as the long poll
> changes we mentioned, we are going to add a new flag 'ENTRY_PIGGYBACK' for
> read. so a read request is either a normal read (without Flag), a fence
> read (flag = FENCE_LEDGER) or a piggyback read (flag = ENTRY_PIGGYBACK).
> Being repeated will be kind of complicated, as you need to loop all
> possible permutation.
> >
> > Ivan Kelly wrote:
> >     This is ugly and shortsighted. There may well be a case in the
> future where two flags need to be specified. What do we do then? Add a
> flags2 field?
> >
> > Sijie Guo wrote:
> >     why this couldn't be a 3rd flag? FENCE_LEDGER_AND_PIGGYBACK?
> >
> >     in your repeated way, let's say you have n flags, you would have n!
> ways to combine them. it is hard to figure out what kind of combination
> works for what situation. as some of your flags are exclusive with others.
> so renaming the combination specifically would make it clear.
> >
> > Ivan Kelly wrote:
> >     as you say, with n flags specified, there are n! combinations. so if
> another flag as added, you will have to add n values to the enum to cover
> the different combinations. whether the flags are exclusive is for the
> application to decide. it shouldnt be implicit in the protocol encoding.
> >
> > Sijie Guo wrote:
> >     same explanation for OperationType is applying here. if n flags
> mostly are used individually, an explicit way will just need to deal with
> around n possibilities. but you need to write lots of if..else branches for
> inferring in an implicit way.
> >
> > Ivan Kelly wrote:
> >     Your assumption here is that all the flag handling code will be in
> one place in a big switch. this isnt the case. I dont know how you have
> implemented piggyback, but i would guess it would be something like.
> >
> >     Response processReadRequest(Request req) {
> >         if (isFencing(req)) {
> >             fenceLedger();
> >         }
> >         byte[] data = fetchEntry(req.getLedgerId(), req.getEntryId());
> >         Response resp = new Response(OK, data);
> >         if (isPiggyback(req)) {
> >             addPiggyback(resp);
> >         }
> >         return resp;
> >     }
> >
> >     Now consider how #isPiggyback and #isFencing would be implemented
> with enums and with individual boolean flags? which is shorter? Which is
> easier to maintain?
> >
> > Sijie Guo wrote:
> >     isFencing => flag == Flag.FENCE_LEDGER
> >     isPiggyback => flag == ENTRY_PIGGYBACK
> >
> >     what is the difference above for maintaining?
> >
> >     using the flag, the semantic is super clear that your request is
> either a fencing request or a piggyback request. it would not happen that
> you received a request that probably have two flags enabled, then what does
> it mean if the requests have two boolean flags enabled, don't consider the
> case (that is always the point that I made for OperationType and Flag
> here)? then which is easier to maintain?
> >
> > Ivan Kelly wrote:
> >     my comment from yesterday doesn't wasnt saved by review board >:|
> >
> >     Anyhow, what i asked was, can you guarantee that there will never
> *ever* be a case where two flags will need to be set on a single op in the
> future?
> >
> > Sijie Guo wrote:
> >     well, I already made a comment on your case: "why this couldn't be a
> 3rd flag? FENCE_LEDGER_AND_PIGGYBACK?", no? and this is how hedwig handles
> subscription mode, 'create', 'attach', 'create_and_attach', no?
> >
> >     and again, as I said in previous comment, if you define flags in an
> explicit way, you would have much clearer branches on what kind of
> operations should be executed on what flags, like below: (take an example,
> A, B, C, A_AND_B, B_AND_A)
> >
> >     switch (flag) {
> >     case A:
> >       a();
> >       break;
> >     case B:
> >       b();
> >       break;
> >     case C:
> >       c();
> >       break;
> >     case A_AND_B:
> >       a();
> >       b();
> >       break;
> >     case B_AND_A:
> >       b();
> >       // other executions between b() and a(), which is different from
> A_AND_B case.
> >       a();
> >       break;
> >     }
> >
> >     but if you define flags in an implicit way, you need to check all
> possible negative cases to avoid the program failed in abnormal cases (e.g.
> bad combinations, bad order of flags). isn't that introducing much harder
> work for maintenance?
> >
> >
> > Rakesh R wrote:
> >     If we have a set of flags, also consider both AND/OR conjunctions
> the combinations may grow and thus increases the complexity of the problem.
> I feel it doesn't matter whether you are using enum type or bool flag, both
> will have 'chain of if conditions' either at the client side or at the
> server side. If I understood correctly the switch case you are talking will
> be added at the server side. Now for setting 'A_AND_B' enum type in the
> request, client side we need to have the 'chain of if conditions' no?.
> >
> >     I could see few advantages of having 'if chain' at the client side,
> server would not worry about the conditional evaluation which may be in a
> critical section. Secondly it would be easy to define strategies against
> enum type and pass it over different layers without worrying about how they
> formed.
> >
> >     If we think the problem space is small and assume we have only few
> set of flags I prefer enum. Before reaching to a conclusion I've one
> question about the number 'n' of flags and how much value 'n' can grow ?.
> Only my worry is, once we set the protocol to enum type, as we all know
> couldn't get another chance to change it later as 'n' increases.
> >
> > Sijie Guo wrote:
> >     > Now for setting 'A_AND_B' enum type in the request, client side we
> need to have the 'chain of if conditions' no?.
> >
> >     why client need to have the chain? client just need to set different
> flag value to indicate different type of single read.
> >
> >     >  how much value 'n' can grow?
> >
> >     I could tell the future. but I don't see it would grow too much. A
> specific enum value would make semantic more clear.
>
> I'm assuming there will be a conditional logic in order to set the flag
> and the code will looks like,
>
> Flag flag = // init with default value
>
> if flag_condition_a satisfies
>     flag = A
> if flag_condition_b satisfies
>     flag = B
> if flag_condition_a satisfies && flag_condition_b satisfies
>     flag = A_AND_B
>
>
> - Rakesh
>


sure. setting flag isn't a problem as you don't need to eliminate negative
cases when adding more flags. but checking flags is, as you need to
eliminate negative cases.


>
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/17895/#review41130
> -----------------------------------------------------------
>
>
> On April 24, 2014, 7:43 a.m., Sijie Guo wrote:
> >
> > -----------------------------------------------------------
> > This is an automatically generated e-mail. To reply, visit:
> > https://reviews.apache.org/r/17895/
> > -----------------------------------------------------------
> >
> > (Updated April 24, 2014, 7:43 a.m.)
> >
> >
> > Review request for bookkeeper and Ivan Kelly.
> >
> >
> > Bugs: BOOKKEEPER-582
> >     https://issues.apache.org/jira/browse/BOOKKEEPER-582
> >
> >
> > Repository: bookkeeper-git
> >
> >
> > Description
> > -------
> >
> > - introducing protobuf support for bookkeeper
> > - for server: introduce packet processor / EnDecoder for different
> protocol supports
> > - for client: change PCBC to use protobuf to send requests
> > - misc changes for protobuf support
> >
> > (bookie server is able for backward compatibility)
> >
> >
> > Diffs
> > -----
> >
> >   bookkeeper-server/pom.xml ebc1198
> >
> bookkeeper-server/src/main/java/org/apache/bookkeeper/bookie/IndexInMemPageMgr.java
> 56487aa
> >
> bookkeeper-server/src/main/java/org/apache/bookkeeper/client/LedgerChecker.java
> 28e23d6
> >
> bookkeeper-server/src/main/java/org/apache/bookkeeper/client/PendingReadOp.java
> fb36b90
> >
> bookkeeper-server/src/main/java/org/apache/bookkeeper/processor/RequestProcessor.java
> 241f369
> >
> bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieProtoEncoding.java
> 1154047
> >
> bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestHandler.java
> b922a82
> >
> bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestProcessor.java
> 8155b22
> >
> bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookkeeperProtocol.java
> PRE-CREATION
> >
> bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBase.java
> PRE-CREATION
> >
> bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBaseV3.java
> PRE-CREATION
> >
> bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PerChannelBookieClient.java
> a10f7d5
> >
> bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessor.java
> PRE-CREATION
> >
> bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessorV3.java
> PRE-CREATION
> >
> bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessor.java
> PRE-CREATION
> >
> bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessorV3.java
> PRE-CREATION
> >   bookkeeper-server/src/main/proto/BookkeeperProtocol.proto PRE-CREATION
> >   bookkeeper-server/src/main/resources/findbugsExclude.xml 97a6156
> >
> bookkeeper-server/src/test/java/org/apache/bookkeeper/proto/TestProtoVersions.java
> 5fcc445
> >
> bookkeeper-server/src/test/java/org/apache/bookkeeper/replication/AuditorPeriodicCheckTest.java
> 3f8496f
> >
> bookkeeper-server/src/test/java/org/apache/bookkeeper/test/BookieClientTest.java
> bc05229
> >
> bookkeeper-server/src/test/java/org/apache/bookkeeper/test/TestBackwardCompat.java
> 8376b46
> >   compat-deps/bookkeeper-server-compat-4.2.0/pom.xml PRE-CREATION
> >   compat-deps/hedwig-server-compat-4.2.0/pom.xml PRE-CREATION
> >   compat-deps/pom.xml f79582d
> >   hedwig-server/pom.xml 06cf01c
> >
> hedwig-server/src/test/java/org/apache/hedwig/server/TestBackwardCompat.java
> 8da109e
> >
> > Diff: https://reviews.apache.org/r/17895/diff/
> >
> >
> > Testing
> > -------
> >
> > unit tests. backward tests.
> >
> >
> > Thanks,
> >
> > Sijie Guo
> >
> >
>
>

Re: Review Request 17895: BOOKKEEPER-582: protobuf support for bookkeeper

Posted by Rakesh R <ra...@huawei.com>.


> On April 23, 2014, 10:22 a.m., Ivan Kelly wrote:
> > bookkeeper-server/src/main/proto/BookkeeperProtocol.proto, line 80
> > <https://reviews.apache.org/r/17895/diff/2/?file=563033#file563033line80>
> >
> >     This would be better served with a boolean. protobuf will keep it compact.
> 
> Sijie Guo wrote:
>     being Flag will make it easier to add other flags in future.
> 
> Ivan Kelly wrote:
>     No it doesn't. Lets say you do add another flag in the future. How do you specify that it's both a FENCE_LEDGER and NEW_FLAG? You need the field to be repeated, and then you need code to loop through the flags. Compared to msg.isFenceLedger(), this seems much more cumbersome.
> 
> Sijie Guo wrote:
>     I don't say this field is bits-set-like of flags. as the long poll changes we mentioned, we are going to add a new flag 'ENTRY_PIGGYBACK' for read. so a read request is either a normal read (without Flag), a fence read (flag = FENCE_LEDGER) or a piggyback read (flag = ENTRY_PIGGYBACK). Being repeated will be kind of complicated, as you need to loop all possible permutation.
> 
> Ivan Kelly wrote:
>     This is ugly and shortsighted. There may well be a case in the future where two flags need to be specified. What do we do then? Add a flags2 field?
> 
> Sijie Guo wrote:
>     why this couldn't be a 3rd flag? FENCE_LEDGER_AND_PIGGYBACK?
>     
>     in your repeated way, let's say you have n flags, you would have n! ways to combine them. it is hard to figure out what kind of combination works for what situation. as some of your flags are exclusive with others. so renaming the combination specifically would make it clear.
> 
> Ivan Kelly wrote:
>     as you say, with n flags specified, there are n! combinations. so if another flag as added, you will have to add n values to the enum to cover the different combinations. whether the flags are exclusive is for the application to decide. it shouldnt be implicit in the protocol encoding.
> 
> Sijie Guo wrote:
>     same explanation for OperationType is applying here. if n flags mostly are used individually, an explicit way will just need to deal with around n possibilities. but you need to write lots of if..else branches for inferring in an implicit way.
> 
> Ivan Kelly wrote:
>     Your assumption here is that all the flag handling code will be in one place in a big switch. this isnt the case. I dont know how you have implemented piggyback, but i would guess it would be something like.
>     
>     Response processReadRequest(Request req) {
>         if (isFencing(req)) {
>             fenceLedger();
>         }
>         byte[] data = fetchEntry(req.getLedgerId(), req.getEntryId());
>         Response resp = new Response(OK, data);
>         if (isPiggyback(req)) {
>             addPiggyback(resp);
>         }
>         return resp;
>     }
>     
>     Now consider how #isPiggyback and #isFencing would be implemented with enums and with individual boolean flags? which is shorter? Which is easier to maintain?
> 
> Sijie Guo wrote:
>     isFencing => flag == Flag.FENCE_LEDGER
>     isPiggyback => flag == ENTRY_PIGGYBACK
>     
>     what is the difference above for maintaining?
>     
>     using the flag, the semantic is super clear that your request is either a fencing request or a piggyback request. it would not happen that you received a request that probably have two flags enabled, then what does it mean if the requests have two boolean flags enabled, don't consider the case (that is always the point that I made for OperationType and Flag here)? then which is easier to maintain?
> 
> Ivan Kelly wrote:
>     my comment from yesterday doesn't wasnt saved by review board >:|
>     
>     Anyhow, what i asked was, can you guarantee that there will never *ever* be a case where two flags will need to be set on a single op in the future?
> 
> Sijie Guo wrote:
>     well, I already made a comment on your case: "why this couldn't be a 3rd flag? FENCE_LEDGER_AND_PIGGYBACK?", no? and this is how hedwig handles subscription mode, 'create', 'attach', 'create_and_attach', no?
>     
>     and again, as I said in previous comment, if you define flags in an explicit way, you would have much clearer branches on what kind of operations should be executed on what flags, like below: (take an example, A, B, C, A_AND_B, B_AND_A)
>     
>     switch (flag) {
>     case A:
>       a();
>       break;
>     case B:
>       b();
>       break;
>     case C:
>       c();
>       break;
>     case A_AND_B:
>       a();
>       b();
>       break;
>     case B_AND_A:
>       b();
>       // other executions between b() and a(), which is different from A_AND_B case.
>       a();
>       break;
>     }
>     
>     but if you define flags in an implicit way, you need to check all possible negative cases to avoid the program failed in abnormal cases (e.g. bad combinations, bad order of flags). isn't that introducing much harder work for maintenance? 
>
> 
> Rakesh R wrote:
>     If we have a set of flags, also consider both AND/OR conjunctions the combinations may grow and thus increases the complexity of the problem. I feel it doesn't matter whether you are using enum type or bool flag, both will have 'chain of if conditions' either at the client side or at the server side. If I understood correctly the switch case you are talking will be added at the server side. Now for setting 'A_AND_B' enum type in the request, client side we need to have the 'chain of if conditions' no?.
>     
>     I could see few advantages of having 'if chain' at the client side, server would not worry about the conditional evaluation which may be in a critical section. Secondly it would be easy to define strategies against enum type and pass it over different layers without worrying about how they formed.
>     
>     If we think the problem space is small and assume we have only few set of flags I prefer enum. Before reaching to a conclusion I've one question about the number 'n' of flags and how much value 'n' can grow ?. Only my worry is, once we set the protocol to enum type, as we all know couldn't get another chance to change it later as 'n' increases.
> 
> Sijie Guo wrote:
>     > Now for setting 'A_AND_B' enum type in the request, client side we need to have the 'chain of if conditions' no?.
>     
>     why client need to have the chain? client just need to set different flag value to indicate different type of single read. 
>     
>     >  how much value 'n' can grow?
>     
>     I could tell the future. but I don't see it would grow too much. A specific enum value would make semantic more clear.

I'm assuming there will be a conditional logic in order to set the flag and the code will looks like,

Flag flag = // init with default value

if flag_condition_a satisfies
    flag = A
if flag_condition_b satisfies
    flag = B
if flag_condition_a satisfies && flag_condition_b satisfies
    flag = A_AND_B


- Rakesh


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/17895/#review41130
-----------------------------------------------------------


On April 24, 2014, 7:43 a.m., Sijie Guo wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/17895/
> -----------------------------------------------------------
> 
> (Updated April 24, 2014, 7:43 a.m.)
> 
> 
> Review request for bookkeeper and Ivan Kelly.
> 
> 
> Bugs: BOOKKEEPER-582
>     https://issues.apache.org/jira/browse/BOOKKEEPER-582
> 
> 
> Repository: bookkeeper-git
> 
> 
> Description
> -------
> 
> - introducing protobuf support for bookkeeper
> - for server: introduce packet processor / EnDecoder for different protocol supports
> - for client: change PCBC to use protobuf to send requests
> - misc changes for protobuf support
> 
> (bookie server is able for backward compatibility) 
> 
> 
> Diffs
> -----
> 
>   bookkeeper-server/pom.xml ebc1198 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/bookie/IndexInMemPageMgr.java 56487aa 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/LedgerChecker.java 28e23d6 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/PendingReadOp.java fb36b90 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/processor/RequestProcessor.java 241f369 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieProtoEncoding.java 1154047 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestHandler.java b922a82 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestProcessor.java 8155b22 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookkeeperProtocol.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBase.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBaseV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PerChannelBookieClient.java a10f7d5 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/proto/BookkeeperProtocol.proto PRE-CREATION 
>   bookkeeper-server/src/main/resources/findbugsExclude.xml 97a6156 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/proto/TestProtoVersions.java 5fcc445 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/replication/AuditorPeriodicCheckTest.java 3f8496f 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/BookieClientTest.java bc05229 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/TestBackwardCompat.java 8376b46 
>   compat-deps/bookkeeper-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/hedwig-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/pom.xml f79582d 
>   hedwig-server/pom.xml 06cf01c 
>   hedwig-server/src/test/java/org/apache/hedwig/server/TestBackwardCompat.java 8da109e 
> 
> Diff: https://reviews.apache.org/r/17895/diff/
> 
> 
> Testing
> -------
> 
> unit tests. backward tests.
> 
> 
> Thanks,
> 
> Sijie Guo
> 
>

Re: Review Request 17895: BOOKKEEPER-582: protobuf support for bookkeeper

Posted by Ivan Kelly <iv...@apache.org>.


> On April 23, 2014, 10:22 a.m., Ivan Kelly wrote:
> > bookkeeper-server/src/main/proto/BookkeeperProtocol.proto, line 80
> > <https://reviews.apache.org/r/17895/diff/2/?file=563033#file563033line80>
> >
> >     This would be better served with a boolean. protobuf will keep it compact.
> 
> Sijie Guo wrote:
>     being Flag will make it easier to add other flags in future.
> 
> Ivan Kelly wrote:
>     No it doesn't. Lets say you do add another flag in the future. How do you specify that it's both a FENCE_LEDGER and NEW_FLAG? You need the field to be repeated, and then you need code to loop through the flags. Compared to msg.isFenceLedger(), this seems much more cumbersome.
> 
> Sijie Guo wrote:
>     I don't say this field is bits-set-like of flags. as the long poll changes we mentioned, we are going to add a new flag 'ENTRY_PIGGYBACK' for read. so a read request is either a normal read (without Flag), a fence read (flag = FENCE_LEDGER) or a piggyback read (flag = ENTRY_PIGGYBACK). Being repeated will be kind of complicated, as you need to loop all possible permutation.
> 
> Ivan Kelly wrote:
>     This is ugly and shortsighted. There may well be a case in the future where two flags need to be specified. What do we do then? Add a flags2 field?
> 
> Sijie Guo wrote:
>     why this couldn't be a 3rd flag? FENCE_LEDGER_AND_PIGGYBACK?
>     
>     in your repeated way, let's say you have n flags, you would have n! ways to combine them. it is hard to figure out what kind of combination works for what situation. as some of your flags are exclusive with others. so renaming the combination specifically would make it clear.

as you say, with n flags specified, there are n! combinations. so if another flag as added, you will have to add n values to the enum to cover the different combinations. whether the flags are exclusive is for the application to decide. it shouldnt be implicit in the protocol encoding. 


> On April 23, 2014, 10:22 a.m., Ivan Kelly wrote:
> > bookkeeper-server/src/main/proto/BookkeeperProtocol.proto, line 104
> > <https://reviews.apache.org/r/17895/diff/2/?file=563033#file563033line104>
> >
> >     You're sending StatusCode twice, every time. Firstly, shouldn't be an enum as stated above. Secondly, shouldn't be required.
> 
> Sijie Guo wrote:
>     > enum
>     
>     as the comments above.
>     
>     > status code twice.
>     
>     the status code for ReadResponse/AddResponse is for individual responses. if we are going to support kind of batch reads, the status code of Response means either the whole batch succeed or not while the individual read responses might have different status codes (e.g OK or NotExists). That is why it exists two places.
>     
>     > required
>     
>     as the comments above
> 
> Ivan Kelly wrote:
>     Per request makes sense. However, in that case, can't you just remove the per packet status?
> 
> Sijie Guo wrote:
>     Nope. the packet status indicates whether the packet succeed or not. say if it is batch read, if the total batch read failed, it would set the whole packet status to be failed and there would be no individual responses in the packet since the whole batch failed.
> 
> Ivan Kelly wrote:
>     Then it should have a different name. Like entryStatus & packetStatus. But then you also have a consistency problem. What is packetStatus is OK, but one entryStatus is an error? Will there be a SOME_OK error? In what scenario would a whole read batch fail?
> 
> Sijie Guo wrote:
>     if ledger isn't exists, then a packet status with NoSuchLedgerExists is returned. if ledger exists, but some entries are missing, so ok is returned for the packet, but NoSuchEntry would be returned for the missing entries.

this would be better handled with a batch intermediatory message, defined like

message Response {
    required BKPacketHeader header = 1;

    optional ReadResponse readResponse = 100;
    optional AddResponse addResponse = 101;
    optional BatchReadResponse batchReadResponse = 102;
}

message ReadResponse {
    required StatusCode status = 1;
    required int64 ledgerId = 2;
    required int64 entryId = 3;
    optional bytes body = 4;
}

message BatchReadResponse {
    optional StatusCode status = 1;
    repeated ReadResponse entries = 2;
}

message AddResponse {
    required StatusCode status = 1;
    required int64 ledgerId = 2;
    required int64 entryId = 3;
}


> On April 23, 2014, 10:22 a.m., Ivan Kelly wrote:
> > bookkeeper-server/src/main/proto/BookkeeperProtocol.proto, line 33
> > <https://reviews.apache.org/r/17895/diff/2/?file=563033#file563033line33>
> >
> >     This should certainly not be an enum. Otherwise we need to bump the protocol version each time we add an error code.
> >     
> >     Imagine the scenario where both server and client are running 4.3.0. Then the server is upgraded with 4.3.1 which a new error EPRINTERONFIRE. It sends this to the client who throws a decode error.
> 
> Sijie Guo wrote:
>     how could being not enum help this? if it is integer, client still has no idea how to interpret, so it is still invalid response from 4.3.0 client. I thought we reached an agreement on enum on the ticket, no?
> 
> Ivan Kelly wrote:
>     So for version and operationtype, enum is ok. These originate at the client, so if the servers are always upgraded at the client, there's no interoperability issues. Status codes originate at the server though, so it is possible for the server to send a statuscode that is unrecognised to a client. The normal way to handle this would be a "else" or "default:" to pass this up to the client as a BKException.UnexpectedConditionException. If it's an enum, this will throw a decode exception in the netty decoder, which is harder to handle.
>     
>     To resolve this on the server side, by checking the version and only sending errors valid for that version, implies two things. Firstly, every error code change will require the version to be bumped and secondly, that there will need to be a list maintained for which errors are valid for each version. This goes against the motivation for using protobuf in the first place.
> 
> Sijie Guo wrote:
>     this is the application level agreement, no? it doesn't matter that u are using a protobuf protocol or using current protocol, or it also doesn't matter that u are using an integer or an enum. in any case, the best way is as you described, you shouldn't send new status code back to an old client, as the new status code is meaningless to the old client.
> 
> Ivan Kelly wrote:
>     but how do you know its an old client? Only by bumping the version number each time you add an error code. In which case you end up with a whole lot of junk like "if (client.version == X) { send A } else if (client.version == Y) { send B } else if (client.version ..." which is exactly what protobuf was designed to avoid (see "A bit of history" on https://developers.google.com/protocol-buffers/docs/overview).
> 
> Sijie Guo wrote:
>     a else or default branch would make the behavior unpredictable as an old client is treating a new status code as some kind of unknown. as you said, you want to treat them as UnexpectedConditionException. But what does UnexpectedConditionException means? doesn't it mean the sever already breaks backward compatibility, since server couldn't satisfy the old client's request.
>     
>     so still, if server wants to be backward compatibility to clients, in any cases, it needs to know what version of protocol that the client is speaking and handle them accordingly, not just let client to do their job in an unexpected way.
>     
>     I don't see any elegant solutions without detecting protocol version. if you have, please describe how not being enum would avoid this.

the default behaviour for an unknown error code is something we already use today.
https://github.com/apache/bookkeeper/blob/trunk/bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PerChannelBookieClient.java#L714

The client only needs to know that the request failed. the point of the different error codes is so that the client could take specific recovery steps. the default behaviour is just to pass the error up. 


> On April 23, 2014, 10:22 a.m., Ivan Kelly wrote:
> > bookkeeper-server/src/main/proto/BookkeeperProtocol.proto, line 65
> > <https://reviews.apache.org/r/17895/diff/2/?file=563033#file563033line65>
> >
> >     Comment 1.
> >     OperationType is redundant. The server can do #hasReadRequest and #hasAddRequest to check the request to check the type. We shouldn't send redundant data over the wire where possible.
> >     
> >     Comment 2.
> >     it better to make the absolute minimum to be required. Required is forever, and these may not be.
> >     
> >     https://developers.google.com/protocol-buffers/docs/proto
> >
> 
> Sijie Guo wrote:
>     > comment 1.
>     
>     OperationType will make request more clear and specify and less if...else branches. And OperationType is used for PCBC to unify all requests handling. so we don't need to have individual maps to maintain requests each time we added a new type of requests.
>     
>     > comment 2.
>     
>     if reply to comment 1 works for u, I don't see any reason why operation would not be a required.
> 
> Ivan Kelly wrote:
>     Ok. I can live with it, though I still think it's a little cumbersome. Regarding requiredness, I still think it should be optional. All fields should be optional by default to give you as much freedom to evolve the protocol in the future as possible. Especially something, which is not 100% essential to the protocol, like this field.
> 
> Sijie Guo wrote:
>     for those fields that already exist in the origin protocol, I don't see we are going to remove them. that's why we put it as required.
> 
> Ivan Kelly wrote:
>     We shouldnt prelude the possibility though. What problem could making them optional cause?
> 
> Sijie Guo wrote:
>     what does an response w/o OperationType mean? How PCBC would handle this? as I said, OperationType is somehow guiding us to dispatch the request and response. so it is required.

the operation type can be inferred from the contents as i said already. So OperationType itself isnt actually required, so we should lock it in at this point.


- Ivan


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/17895/#review41130
-----------------------------------------------------------


On April 24, 2014, 7:43 a.m., Sijie Guo wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/17895/
> -----------------------------------------------------------
> 
> (Updated April 24, 2014, 7:43 a.m.)
> 
> 
> Review request for bookkeeper and Ivan Kelly.
> 
> 
> Bugs: BOOKKEEPER-582
>     https://issues.apache.org/jira/browse/BOOKKEEPER-582
> 
> 
> Repository: bookkeeper-git
> 
> 
> Description
> -------
> 
> - introducing protobuf support for bookkeeper
> - for server: introduce packet processor / EnDecoder for different protocol supports
> - for client: change PCBC to use protobuf to send requests
> - misc changes for protobuf support
> 
> (bookie server is able for backward compatibility) 
> 
> 
> Diffs
> -----
> 
>   bookkeeper-server/pom.xml ebc1198 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/bookie/IndexInMemPageMgr.java 56487aa 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/LedgerChecker.java 28e23d6 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/PendingReadOp.java fb36b90 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/processor/RequestProcessor.java 241f369 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieProtoEncoding.java 1154047 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestHandler.java b922a82 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestProcessor.java 8155b22 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookkeeperProtocol.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBase.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBaseV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PerChannelBookieClient.java a10f7d5 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/proto/BookkeeperProtocol.proto PRE-CREATION 
>   bookkeeper-server/src/main/resources/findbugsExclude.xml 97a6156 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/proto/TestProtoVersions.java 5fcc445 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/replication/AuditorPeriodicCheckTest.java 3f8496f 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/BookieClientTest.java bc05229 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/TestBackwardCompat.java 8376b46 
>   compat-deps/bookkeeper-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/hedwig-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/pom.xml f79582d 
>   hedwig-server/pom.xml 06cf01c 
>   hedwig-server/src/test/java/org/apache/hedwig/server/TestBackwardCompat.java 8da109e 
> 
> Diff: https://reviews.apache.org/r/17895/diff/
> 
> 
> Testing
> -------
> 
> unit tests. backward tests.
> 
> 
> Thanks,
> 
> Sijie Guo
> 
>

Re: Review Request 17895: BOOKKEEPER-582: protobuf support for bookkeeper

Posted by Rakesh R <ra...@huawei.com>.


> On April 23, 2014, 10:22 a.m., Ivan Kelly wrote:
> > bookkeeper-server/src/main/proto/BookkeeperProtocol.proto, line 33
> > <https://reviews.apache.org/r/17895/diff/2/?file=563033#file563033line33>
> >
> >     This should certainly not be an enum. Otherwise we need to bump the protocol version each time we add an error code.
> >     
> >     Imagine the scenario where both server and client are running 4.3.0. Then the server is upgraded with 4.3.1 which a new error EPRINTERONFIRE. It sends this to the client who throws a decode error.
> 
> Sijie Guo wrote:
>     how could being not enum help this? if it is integer, client still has no idea how to interpret, so it is still invalid response from 4.3.0 client. I thought we reached an agreement on enum on the ticket, no?
> 
> Ivan Kelly wrote:
>     So for version and operationtype, enum is ok. These originate at the client, so if the servers are always upgraded at the client, there's no interoperability issues. Status codes originate at the server though, so it is possible for the server to send a statuscode that is unrecognised to a client. The normal way to handle this would be a "else" or "default:" to pass this up to the client as a BKException.UnexpectedConditionException. If it's an enum, this will throw a decode exception in the netty decoder, which is harder to handle.
>     
>     To resolve this on the server side, by checking the version and only sending errors valid for that version, implies two things. Firstly, every error code change will require the version to be bumped and secondly, that there will need to be a list maintained for which errors are valid for each version. This goes against the motivation for using protobuf in the first place.
> 
> Sijie Guo wrote:
>     this is the application level agreement, no? it doesn't matter that u are using a protobuf protocol or using current protocol, or it also doesn't matter that u are using an integer or an enum. in any case, the best way is as you described, you shouldn't send new status code back to an old client, as the new status code is meaningless to the old client.
> 
> Ivan Kelly wrote:
>     but how do you know its an old client? Only by bumping the version number each time you add an error code. In which case you end up with a whole lot of junk like "if (client.version == X) { send A } else if (client.version == Y) { send B } else if (client.version ..." which is exactly what protobuf was designed to avoid (see "A bit of history" on https://developers.google.com/protocol-buffers/docs/overview).
> 
> Sijie Guo wrote:
>     a else or default branch would make the behavior unpredictable as an old client is treating a new status code as some kind of unknown. as you said, you want to treat them as UnexpectedConditionException. But what does UnexpectedConditionException means? doesn't it mean the sever already breaks backward compatibility, since server couldn't satisfy the old client's request.
>     
>     so still, if server wants to be backward compatibility to clients, in any cases, it needs to know what version of protocol that the client is speaking and handle them accordingly, not just let client to do their job in an unexpected way.
>     
>     I don't see any elegant solutions without detecting protocol version. if you have, please describe how not being enum would avoid this.
> 
> Ivan Kelly wrote:
>     the default behaviour for an unknown error code is something we already use today.
>     https://github.com/apache/bookkeeper/blob/trunk/bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PerChannelBookieClient.java#L714
>     
>     The client only needs to know that the request failed. the point of the different error codes is so that the client could take specific recovery steps. the default behaviour is just to pass the error up.
> 
> Sijie Guo wrote:
>     the default behavior was there just for all already known status codes. but it doesn't mean it is correct for any unknown status codes. and when u are saying 'the client only needs to know that the request failed', you are making an assumption that there is only one status code indicating OK, other status code should be taken as failed. but it isn't true. say in an old protocol, we supported range reads, it responded with OK, list of entry response (0 = <data>, 1 = missing, 2 = missing, 3 = <data>). if we are going to improve our protocol to make communication more efficient, we are going to change the protocol to get rid of transferring missing entries: responding with PARTIAL_OK, list of existing entries (0 = <data>, 3 = <data>). 
>     
>     in this case, if server doesn't distinguish the client's protocol, just respond every range reads with PARTIAL_OK, would did break the compatibility with old protocol, as old protocol treats it as failure by default behavior. in order to maintain backward compatibility, server needs to detect the client's protocol and responds accordingly. as what I said, for backward compatibility, a protocol doesn't really help if it involves behavior in application agreement. and a default behavior is not exact right.
>     
>     for me, using protocol. it means that it is easy for us to add new requests type, add new fields in existing requests. besides that, we need to keep the backward compatibility in our level.
> 
> Ivan Kelly wrote:
>     when i say that 'the client only needs to know that the request failed', it means that the client only needs to recognise the statuses which indicate success. for any request, the status codes which indicate success should never change. For a read request or add request, only OK is SUCCESS. For range read,  only PARTIAL_OK and OK are success. But the client will never send a range read request unless it already knows about PARTIAL_OK.
> 
> Sijie Guo wrote:
>     > “But the client will never send a range read request unless it already knows about PARTIAL_OK.” 
>     
>     the example that I made is that the range read introduced with OK, but if it is going to evolved to have PARTIAL_OK. then that will be an problem.
> 
> Ivan Kelly wrote:
>     Partial_ok doesn't make sense if you're using the concept of packet status and operation status (as mentioned below).
> 
> Sijie Guo wrote:
>     well, if u are talking about a specific case (e.g. range read), I might agree with u. but if you read my comments, it is just the case that I explained how the protocol might be evolved. And my point is and always will be for backward compatibility, the server shouldn't send any unknown codes/fields back to clients that speaks old protocol, this is part of application-level agreement, no matter using enum or integer.
> 
> Rakesh R wrote:
>     Using enum is more readable and would be good for newcomers too. Assume a case where we are introducing new EC for an existing request type at the side server side, EC#NEW_ERR_CODE in 4.3.1 and client is old one 4.3.0. Ideally in this case, bk client should say its unknown code.
>     
>     Does this create any parsing issues at the protobuf ?. If not, I'm OK using enum for the StatusCode too.
> 
> Sijie Guo wrote:
>     if you read the conversation about this, my point is that for correct backward compatibility, we should avoid sending unknown error codes back to an old client.
> 
> Rakesh R wrote:
>     So server should have version specific checks and generates the error codes, isn't it ?.
> 
> Sijie Guo wrote:
>     yes. exact as what I pointed. sending responses matching exact version of protocol, isn't that exactly for application level backward compatible? why this would be the concern?
> 
> Rakesh R wrote:
>     There is no big concern here. I'm trying to understand the current approach and the future path to avoid any compatibility issues later.
> 
> Sijie Guo wrote:
>     for backward compatibility, it is comprised of wire compatibility and application-semantic compatibility. using protobuf, we could easily achieve wire compatibility by adding new optional fields. for application-semantic, the server needs to detect what version of the client is talking, and send correct version of responses according to its version. the version field in the request/response structure helps achieving this.

Maintaining version list has its own complexities, but again it depends on the client side requirements. As I know protobuf parser would not get decode exceptions if any unknown enum code comes from server, instead this will return a null value. If this is the behavior of protobuf, then today its not a blocker for this patch. Because in your patch, you have already handled unknown error code in PerChannelBookieClient#statusCodeToExceptionCode() and treats this code as an op failure.


- Rakesh


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/17895/#review41130
-----------------------------------------------------------


On April 24, 2014, 7:43 a.m., Sijie Guo wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/17895/
> -----------------------------------------------------------
> 
> (Updated April 24, 2014, 7:43 a.m.)
> 
> 
> Review request for bookkeeper and Ivan Kelly.
> 
> 
> Bugs: BOOKKEEPER-582
>     https://issues.apache.org/jira/browse/BOOKKEEPER-582
> 
> 
> Repository: bookkeeper-git
> 
> 
> Description
> -------
> 
> - introducing protobuf support for bookkeeper
> - for server: introduce packet processor / EnDecoder for different protocol supports
> - for client: change PCBC to use protobuf to send requests
> - misc changes for protobuf support
> 
> (bookie server is able for backward compatibility) 
> 
> 
> Diffs
> -----
> 
>   bookkeeper-server/pom.xml ebc1198 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/bookie/IndexInMemPageMgr.java 56487aa 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/LedgerChecker.java 28e23d6 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/PendingReadOp.java fb36b90 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/processor/RequestProcessor.java 241f369 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieProtoEncoding.java 1154047 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestHandler.java b922a82 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestProcessor.java 8155b22 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookkeeperProtocol.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBase.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBaseV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PerChannelBookieClient.java a10f7d5 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/proto/BookkeeperProtocol.proto PRE-CREATION 
>   bookkeeper-server/src/main/resources/findbugsExclude.xml 97a6156 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/proto/TestProtoVersions.java 5fcc445 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/replication/AuditorPeriodicCheckTest.java 3f8496f 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/BookieClientTest.java bc05229 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/TestBackwardCompat.java 8376b46 
>   compat-deps/bookkeeper-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/hedwig-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/pom.xml f79582d 
>   hedwig-server/pom.xml 06cf01c 
>   hedwig-server/src/test/java/org/apache/hedwig/server/TestBackwardCompat.java 8da109e 
> 
> Diff: https://reviews.apache.org/r/17895/diff/
> 
> 
> Testing
> -------
> 
> unit tests. backward tests.
> 
> 
> Thanks,
> 
> Sijie Guo
> 
>

Re: Review Request 17895: BOOKKEEPER-582: protobuf support for bookkeeper

Posted by Sijie Guo <gu...@gmail.com>.


> On April 23, 2014, 10:22 a.m., Ivan Kelly wrote:
> > bookkeeper-server/src/main/proto/BookkeeperProtocol.proto, line 33
> > <https://reviews.apache.org/r/17895/diff/2/?file=563033#file563033line33>
> >
> >     This should certainly not be an enum. Otherwise we need to bump the protocol version each time we add an error code.
> >     
> >     Imagine the scenario where both server and client are running 4.3.0. Then the server is upgraded with 4.3.1 which a new error EPRINTERONFIRE. It sends this to the client who throws a decode error.
> 
> Sijie Guo wrote:
>     how could being not enum help this? if it is integer, client still has no idea how to interpret, so it is still invalid response from 4.3.0 client. I thought we reached an agreement on enum on the ticket, no?
> 
> Ivan Kelly wrote:
>     So for version and operationtype, enum is ok. These originate at the client, so if the servers are always upgraded at the client, there's no interoperability issues. Status codes originate at the server though, so it is possible for the server to send a statuscode that is unrecognised to a client. The normal way to handle this would be a "else" or "default:" to pass this up to the client as a BKException.UnexpectedConditionException. If it's an enum, this will throw a decode exception in the netty decoder, which is harder to handle.
>     
>     To resolve this on the server side, by checking the version and only sending errors valid for that version, implies two things. Firstly, every error code change will require the version to be bumped and secondly, that there will need to be a list maintained for which errors are valid for each version. This goes against the motivation for using protobuf in the first place.
> 
> Sijie Guo wrote:
>     this is the application level agreement, no? it doesn't matter that u are using a protobuf protocol or using current protocol, or it also doesn't matter that u are using an integer or an enum. in any case, the best way is as you described, you shouldn't send new status code back to an old client, as the new status code is meaningless to the old client.
> 
> Ivan Kelly wrote:
>     but how do you know its an old client? Only by bumping the version number each time you add an error code. In which case you end up with a whole lot of junk like "if (client.version == X) { send A } else if (client.version == Y) { send B } else if (client.version ..." which is exactly what protobuf was designed to avoid (see "A bit of history" on https://developers.google.com/protocol-buffers/docs/overview).
> 
> Sijie Guo wrote:
>     a else or default branch would make the behavior unpredictable as an old client is treating a new status code as some kind of unknown. as you said, you want to treat them as UnexpectedConditionException. But what does UnexpectedConditionException means? doesn't it mean the sever already breaks backward compatibility, since server couldn't satisfy the old client's request.
>     
>     so still, if server wants to be backward compatibility to clients, in any cases, it needs to know what version of protocol that the client is speaking and handle them accordingly, not just let client to do their job in an unexpected way.
>     
>     I don't see any elegant solutions without detecting protocol version. if you have, please describe how not being enum would avoid this.
> 
> Ivan Kelly wrote:
>     the default behaviour for an unknown error code is something we already use today.
>     https://github.com/apache/bookkeeper/blob/trunk/bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PerChannelBookieClient.java#L714
>     
>     The client only needs to know that the request failed. the point of the different error codes is so that the client could take specific recovery steps. the default behaviour is just to pass the error up.
> 
> Sijie Guo wrote:
>     the default behavior was there just for all already known status codes. but it doesn't mean it is correct for any unknown status codes. and when u are saying 'the client only needs to know that the request failed', you are making an assumption that there is only one status code indicating OK, other status code should be taken as failed. but it isn't true. say in an old protocol, we supported range reads, it responded with OK, list of entry response (0 = <data>, 1 = missing, 2 = missing, 3 = <data>). if we are going to improve our protocol to make communication more efficient, we are going to change the protocol to get rid of transferring missing entries: responding with PARTIAL_OK, list of existing entries (0 = <data>, 3 = <data>). 
>     
>     in this case, if server doesn't distinguish the client's protocol, just respond every range reads with PARTIAL_OK, would did break the compatibility with old protocol, as old protocol treats it as failure by default behavior. in order to maintain backward compatibility, server needs to detect the client's protocol and responds accordingly. as what I said, for backward compatibility, a protocol doesn't really help if it involves behavior in application agreement. and a default behavior is not exact right.
>     
>     for me, using protocol. it means that it is easy for us to add new requests type, add new fields in existing requests. besides that, we need to keep the backward compatibility in our level.
> 
> Ivan Kelly wrote:
>     when i say that 'the client only needs to know that the request failed', it means that the client only needs to recognise the statuses which indicate success. for any request, the status codes which indicate success should never change. For a read request or add request, only OK is SUCCESS. For range read,  only PARTIAL_OK and OK are success. But the client will never send a range read request unless it already knows about PARTIAL_OK.

> “But the client will never send a range read request unless it already knows about PARTIAL_OK.” 

the example that I made is that the range read introduced with OK, but if it is going to evolved to have PARTIAL_OK. then that will be an problem. 


> On April 23, 2014, 10:22 a.m., Ivan Kelly wrote:
> > bookkeeper-server/src/main/proto/BookkeeperProtocol.proto, line 80
> > <https://reviews.apache.org/r/17895/diff/2/?file=563033#file563033line80>
> >
> >     This would be better served with a boolean. protobuf will keep it compact.
> 
> Sijie Guo wrote:
>     being Flag will make it easier to add other flags in future.
> 
> Ivan Kelly wrote:
>     No it doesn't. Lets say you do add another flag in the future. How do you specify that it's both a FENCE_LEDGER and NEW_FLAG? You need the field to be repeated, and then you need code to loop through the flags. Compared to msg.isFenceLedger(), this seems much more cumbersome.
> 
> Sijie Guo wrote:
>     I don't say this field is bits-set-like of flags. as the long poll changes we mentioned, we are going to add a new flag 'ENTRY_PIGGYBACK' for read. so a read request is either a normal read (without Flag), a fence read (flag = FENCE_LEDGER) or a piggyback read (flag = ENTRY_PIGGYBACK). Being repeated will be kind of complicated, as you need to loop all possible permutation.
> 
> Ivan Kelly wrote:
>     This is ugly and shortsighted. There may well be a case in the future where two flags need to be specified. What do we do then? Add a flags2 field?
> 
> Sijie Guo wrote:
>     why this couldn't be a 3rd flag? FENCE_LEDGER_AND_PIGGYBACK?
>     
>     in your repeated way, let's say you have n flags, you would have n! ways to combine them. it is hard to figure out what kind of combination works for what situation. as some of your flags are exclusive with others. so renaming the combination specifically would make it clear.
> 
> Ivan Kelly wrote:
>     as you say, with n flags specified, there are n! combinations. so if another flag as added, you will have to add n values to the enum to cover the different combinations. whether the flags are exclusive is for the application to decide. it shouldnt be implicit in the protocol encoding.
> 
> Sijie Guo wrote:
>     same explanation for OperationType is applying here. if n flags mostly are used individually, an explicit way will just need to deal with around n possibilities. but you need to write lots of if..else branches for inferring in an implicit way.
> 
> Ivan Kelly wrote:
>     Your assumption here is that all the flag handling code will be in one place in a big switch. this isnt the case. I dont know how you have implemented piggyback, but i would guess it would be something like.
>     
>     Response processReadRequest(Request req) {
>         if (isFencing(req)) {
>             fenceLedger();
>         }
>         byte[] data = fetchEntry(req.getLedgerId(), req.getEntryId());
>         Response resp = new Response(OK, data);
>         if (isPiggyback(req)) {
>             addPiggyback(resp);
>         }
>         return resp;
>     }
>     
>     Now consider how #isPiggyback and #isFencing would be implemented with enums and with individual boolean flags? which is shorter? Which is easier to maintain?

isFencing => flag == Flag.FENCE_LEDGER
isPiggyback => flag == ENTRY_PIGGYBACK

what is the difference above for maintaining?

using the flag, the semantic is super clear that your request is either a fencing request or a piggyback request. it would not happen that you received a request that probably have two flags enabled, then what does it mean if the requests have two boolean flags enabled, don't consider the case (that is always the point that I made for OperationType and Flag here)? then which is easier to maintain?


> On April 23, 2014, 10:22 a.m., Ivan Kelly wrote:
> > bookkeeper-server/src/main/proto/BookkeeperProtocol.proto, line 104
> > <https://reviews.apache.org/r/17895/diff/2/?file=563033#file563033line104>
> >
> >     You're sending StatusCode twice, every time. Firstly, shouldn't be an enum as stated above. Secondly, shouldn't be required.
> 
> Sijie Guo wrote:
>     > enum
>     
>     as the comments above.
>     
>     > status code twice.
>     
>     the status code for ReadResponse/AddResponse is for individual responses. if we are going to support kind of batch reads, the status code of Response means either the whole batch succeed or not while the individual read responses might have different status codes (e.g OK or NotExists). That is why it exists two places.
>     
>     > required
>     
>     as the comments above
> 
> Ivan Kelly wrote:
>     Per request makes sense. However, in that case, can't you just remove the per packet status?
> 
> Sijie Guo wrote:
>     Nope. the packet status indicates whether the packet succeed or not. say if it is batch read, if the total batch read failed, it would set the whole packet status to be failed and there would be no individual responses in the packet since the whole batch failed.
> 
> Ivan Kelly wrote:
>     Then it should have a different name. Like entryStatus & packetStatus. But then you also have a consistency problem. What is packetStatus is OK, but one entryStatus is an error? Will there be a SOME_OK error? In what scenario would a whole read batch fail?
> 
> Sijie Guo wrote:
>     if ledger isn't exists, then a packet status with NoSuchLedgerExists is returned. if ledger exists, but some entries are missing, so ok is returned for the packet, but NoSuchEntry would be returned for the missing entries.
> 
> Ivan Kelly wrote:
>     this would be better handled with a batch intermediatory message, defined like
>     
>     message Response {
>         required BKPacketHeader header = 1;
>     
>         optional ReadResponse readResponse = 100;
>         optional AddResponse addResponse = 101;
>         optional BatchReadResponse batchReadResponse = 102;
>     }
>     
>     message ReadResponse {
>         required StatusCode status = 1;
>         required int64 ledgerId = 2;
>         required int64 entryId = 3;
>         optional bytes body = 4;
>     }
>     
>     message BatchReadResponse {
>         optional StatusCode status = 1;
>         repeated ReadResponse entries = 2;
>     }
>     
>     message AddResponse {
>         required StatusCode status = 1;
>         required int64 ledgerId = 2;
>         required int64 entryId = 3;
>     }
>

the point of differentiating the status code in packet from the one in operations. there are common status codes which are in packet level not related to individual operations, like 'bad request', 'authentication failure' etc, in this case they could be handled in packet level rather than operations level. otherwise, you need to add duplicated logic to handle those common things in operation responses each time you added new type of requests. doesn't this make a call for separating packet status from operation status?


- Sijie


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/17895/#review41130
-----------------------------------------------------------


On April 24, 2014, 7:43 a.m., Sijie Guo wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/17895/
> -----------------------------------------------------------
> 
> (Updated April 24, 2014, 7:43 a.m.)
> 
> 
> Review request for bookkeeper and Ivan Kelly.
> 
> 
> Bugs: BOOKKEEPER-582
>     https://issues.apache.org/jira/browse/BOOKKEEPER-582
> 
> 
> Repository: bookkeeper-git
> 
> 
> Description
> -------
> 
> - introducing protobuf support for bookkeeper
> - for server: introduce packet processor / EnDecoder for different protocol supports
> - for client: change PCBC to use protobuf to send requests
> - misc changes for protobuf support
> 
> (bookie server is able for backward compatibility) 
> 
> 
> Diffs
> -----
> 
>   bookkeeper-server/pom.xml ebc1198 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/bookie/IndexInMemPageMgr.java 56487aa 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/LedgerChecker.java 28e23d6 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/PendingReadOp.java fb36b90 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/processor/RequestProcessor.java 241f369 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieProtoEncoding.java 1154047 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestHandler.java b922a82 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestProcessor.java 8155b22 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookkeeperProtocol.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBase.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBaseV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PerChannelBookieClient.java a10f7d5 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/proto/BookkeeperProtocol.proto PRE-CREATION 
>   bookkeeper-server/src/main/resources/findbugsExclude.xml 97a6156 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/proto/TestProtoVersions.java 5fcc445 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/replication/AuditorPeriodicCheckTest.java 3f8496f 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/BookieClientTest.java bc05229 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/TestBackwardCompat.java 8376b46 
>   compat-deps/bookkeeper-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/hedwig-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/pom.xml f79582d 
>   hedwig-server/pom.xml 06cf01c 
>   hedwig-server/src/test/java/org/apache/hedwig/server/TestBackwardCompat.java 8da109e 
> 
> Diff: https://reviews.apache.org/r/17895/diff/
> 
> 
> Testing
> -------
> 
> unit tests. backward tests.
> 
> 
> Thanks,
> 
> Sijie Guo
> 
>

Re: Review Request 17895: BOOKKEEPER-582: protobuf support for bookkeeper

Posted by Sijie Guo <gu...@gmail.com>.


> On April 23, 2014, 10:22 a.m., Ivan Kelly wrote:
> >
> 
> Sijie Guo wrote:
>     ok. let me step back. how bad is the current protocol? if no, why we keep arguing on this? as those changes will break our system, then I don't see the value of contributing our patches back to the community.
> 
> Ivan Kelly wrote:
>     For me, the motivating change was auth. The initial drop I did for auth[1] was based in PB to allow for auth providers to include their own extensions with PB and not have to deal with parsing. This was mixing old parsing and PB though, so I held off the change until PB went in, so that we wouldnt have two parsing mechanisms being actively developed.
>     
>     For me, this motivation is still valid. Having two decoding mechanisms is ugly and hacky. With the plan to add batch reads,it also makes sense to be easily able to add messages.
>     
>     Another motivation is to reduce the variation between the branches. We currently have 3 branchs, the apache branch, the twitter branch and the yahoo branch (perhaps huawei also have a branch). These will unlikely ever be 100% identical, but I had hoped that we could keep the difference to a minimum to allow for us to be able to benefit from each others changes.
>     
>     That said, changes from all sides need to go through the full review process before going in. Both companies have different production usecases, roadmaps, and rollout mechanisms, so assumptions may not hold across organisations.
>     
>     To bring it back to the current patch, and your initial question, the current protocol isn't terrible. The code for it is a hell of a lot cleaner than it was 2 years ago. However, it's cumbersome to add anything to the protocol, mostly because of decisions taken early on, (such as the difference in position of ledgerid and entryid in read and add requests). I was hoping we could avoid locking ourselves into something like this again. 
>     
>     [1] https://github.com/ivankelly/bookkeeper/commits/BookKeeperAuth
> 
> Sijie Guo wrote:
>     ok. replies on your individual concerns.
> 
> Ivan Kelly wrote:
>     We seem to be going round in circles here. I've replied below. But to compromise on somethings, if you change the flags and only have double statuses for responses that need them (i.e. add an intermediate message), I can live with enum status codes, operationType and a whole lot of stuff being required when it should be optional. If you make those changes, Ill push the commit. Otherwise, we need to bring in a tiebreaker.

sure. I also replied all your comments. if I missed anyone, let me know.


> On April 23, 2014, 10:22 a.m., Ivan Kelly wrote:
> > bookkeeper-server/src/main/proto/BookkeeperProtocol.proto, line 80
> > <https://reviews.apache.org/r/17895/diff/2/?file=563033#file563033line80>
> >
> >     This would be better served with a boolean. protobuf will keep it compact.
> 
> Sijie Guo wrote:
>     being Flag will make it easier to add other flags in future.
> 
> Ivan Kelly wrote:
>     No it doesn't. Lets say you do add another flag in the future. How do you specify that it's both a FENCE_LEDGER and NEW_FLAG? You need the field to be repeated, and then you need code to loop through the flags. Compared to msg.isFenceLedger(), this seems much more cumbersome.
> 
> Sijie Guo wrote:
>     I don't say this field is bits-set-like of flags. as the long poll changes we mentioned, we are going to add a new flag 'ENTRY_PIGGYBACK' for read. so a read request is either a normal read (without Flag), a fence read (flag = FENCE_LEDGER) or a piggyback read (flag = ENTRY_PIGGYBACK). Being repeated will be kind of complicated, as you need to loop all possible permutation.
> 
> Ivan Kelly wrote:
>     This is ugly and shortsighted. There may well be a case in the future where two flags need to be specified. What do we do then? Add a flags2 field?
> 
> Sijie Guo wrote:
>     why this couldn't be a 3rd flag? FENCE_LEDGER_AND_PIGGYBACK?
>     
>     in your repeated way, let's say you have n flags, you would have n! ways to combine them. it is hard to figure out what kind of combination works for what situation. as some of your flags are exclusive with others. so renaming the combination specifically would make it clear.
> 
> Ivan Kelly wrote:
>     as you say, with n flags specified, there are n! combinations. so if another flag as added, you will have to add n values to the enum to cover the different combinations. whether the flags are exclusive is for the application to decide. it shouldnt be implicit in the protocol encoding.
> 
> Sijie Guo wrote:
>     same explanation for OperationType is applying here. if n flags mostly are used individually, an explicit way will just need to deal with around n possibilities. but you need to write lots of if..else branches for inferring in an implicit way.
> 
> Ivan Kelly wrote:
>     Your assumption here is that all the flag handling code will be in one place in a big switch. this isnt the case. I dont know how you have implemented piggyback, but i would guess it would be something like.
>     
>     Response processReadRequest(Request req) {
>         if (isFencing(req)) {
>             fenceLedger();
>         }
>         byte[] data = fetchEntry(req.getLedgerId(), req.getEntryId());
>         Response resp = new Response(OK, data);
>         if (isPiggyback(req)) {
>             addPiggyback(resp);
>         }
>         return resp;
>     }
>     
>     Now consider how #isPiggyback and #isFencing would be implemented with enums and with individual boolean flags? which is shorter? Which is easier to maintain?
> 
> Sijie Guo wrote:
>     isFencing => flag == Flag.FENCE_LEDGER
>     isPiggyback => flag == ENTRY_PIGGYBACK
>     
>     what is the difference above for maintaining?
>     
>     using the flag, the semantic is super clear that your request is either a fencing request or a piggyback request. it would not happen that you received a request that probably have two flags enabled, then what does it mean if the requests have two boolean flags enabled, don't consider the case (that is always the point that I made for OperationType and Flag here)? then which is easier to maintain?
> 
> Ivan Kelly wrote:
>     my comment from yesterday doesn't wasnt saved by review board >:|
>     
>     Anyhow, what i asked was, can you guarantee that there will never *ever* be a case where two flags will need to be set on a single op in the future?

well, I already made a comment on your case: "why this couldn't be a 3rd flag? FENCE_LEDGER_AND_PIGGYBACK?", no? and this is how hedwig handles subscription mode, 'create', 'attach', 'create_and_attach', no?

and again, as I said in previous comment, if you define flags in an explicit way, you would have much clearer branches on what kind of operations should be executed on what flags, like below: (take an example, A, B, C, A_AND_B, B_AND_A)

switch (flag) {
case A:
  a();
  break;
case B:
  b();
  break;
case C:
  c();
  break;
case A_AND_B:
  a();
  b();
  break;
case B_AND_A:
  b();
  // other executions between b() and a(), which is different from A_AND_B case.
  a();
  break;
}

but if you define flags in an implicit way, you need to check all possible negative cases to avoid the program failed in abnormal cases (e.g. bad combinations, bad order of flags). isn't that introducing much harder work for maintenance? 


- Sijie


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/17895/#review41130
-----------------------------------------------------------


On April 24, 2014, 7:43 a.m., Sijie Guo wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/17895/
> -----------------------------------------------------------
> 
> (Updated April 24, 2014, 7:43 a.m.)
> 
> 
> Review request for bookkeeper and Ivan Kelly.
> 
> 
> Bugs: BOOKKEEPER-582
>     https://issues.apache.org/jira/browse/BOOKKEEPER-582
> 
> 
> Repository: bookkeeper-git
> 
> 
> Description
> -------
> 
> - introducing protobuf support for bookkeeper
> - for server: introduce packet processor / EnDecoder for different protocol supports
> - for client: change PCBC to use protobuf to send requests
> - misc changes for protobuf support
> 
> (bookie server is able for backward compatibility) 
> 
> 
> Diffs
> -----
> 
>   bookkeeper-server/pom.xml ebc1198 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/bookie/IndexInMemPageMgr.java 56487aa 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/LedgerChecker.java 28e23d6 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/PendingReadOp.java fb36b90 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/processor/RequestProcessor.java 241f369 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieProtoEncoding.java 1154047 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestHandler.java b922a82 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestProcessor.java 8155b22 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookkeeperProtocol.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBase.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBaseV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PerChannelBookieClient.java a10f7d5 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/proto/BookkeeperProtocol.proto PRE-CREATION 
>   bookkeeper-server/src/main/resources/findbugsExclude.xml 97a6156 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/proto/TestProtoVersions.java 5fcc445 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/replication/AuditorPeriodicCheckTest.java 3f8496f 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/BookieClientTest.java bc05229 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/TestBackwardCompat.java 8376b46 
>   compat-deps/bookkeeper-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/hedwig-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/pom.xml f79582d 
>   hedwig-server/pom.xml 06cf01c 
>   hedwig-server/src/test/java/org/apache/hedwig/server/TestBackwardCompat.java 8da109e 
> 
> Diff: https://reviews.apache.org/r/17895/diff/
> 
> 
> Testing
> -------
> 
> unit tests. backward tests.
> 
> 
> Thanks,
> 
> Sijie Guo
> 
>

Re: Review Request 17895: BOOKKEEPER-582: protobuf support for bookkeeper

Posted by Sijie Guo <gu...@gmail.com>.


> On April 23, 2014, 10:22 a.m., Ivan Kelly wrote:
> > bookkeeper-server/src/main/proto/BookkeeperProtocol.proto, line 33
> > <https://reviews.apache.org/r/17895/diff/2/?file=563033#file563033line33>
> >
> >     This should certainly not be an enum. Otherwise we need to bump the protocol version each time we add an error code.
> >     
> >     Imagine the scenario where both server and client are running 4.3.0. Then the server is upgraded with 4.3.1 which a new error EPRINTERONFIRE. It sends this to the client who throws a decode error.
> 
> Sijie Guo wrote:
>     how could being not enum help this? if it is integer, client still has no idea how to interpret, so it is still invalid response from 4.3.0 client. I thought we reached an agreement on enum on the ticket, no?
> 
> Ivan Kelly wrote:
>     So for version and operationtype, enum is ok. These originate at the client, so if the servers are always upgraded at the client, there's no interoperability issues. Status codes originate at the server though, so it is possible for the server to send a statuscode that is unrecognised to a client. The normal way to handle this would be a "else" or "default:" to pass this up to the client as a BKException.UnexpectedConditionException. If it's an enum, this will throw a decode exception in the netty decoder, which is harder to handle.
>     
>     To resolve this on the server side, by checking the version and only sending errors valid for that version, implies two things. Firstly, every error code change will require the version to be bumped and secondly, that there will need to be a list maintained for which errors are valid for each version. This goes against the motivation for using protobuf in the first place.
> 
> Sijie Guo wrote:
>     this is the application level agreement, no? it doesn't matter that u are using a protobuf protocol or using current protocol, or it also doesn't matter that u are using an integer or an enum. in any case, the best way is as you described, you shouldn't send new status code back to an old client, as the new status code is meaningless to the old client.
> 
> Ivan Kelly wrote:
>     but how do you know its an old client? Only by bumping the version number each time you add an error code. In which case you end up with a whole lot of junk like "if (client.version == X) { send A } else if (client.version == Y) { send B } else if (client.version ..." which is exactly what protobuf was designed to avoid (see "A bit of history" on https://developers.google.com/protocol-buffers/docs/overview).
> 
> Sijie Guo wrote:
>     a else or default branch would make the behavior unpredictable as an old client is treating a new status code as some kind of unknown. as you said, you want to treat them as UnexpectedConditionException. But what does UnexpectedConditionException means? doesn't it mean the sever already breaks backward compatibility, since server couldn't satisfy the old client's request.
>     
>     so still, if server wants to be backward compatibility to clients, in any cases, it needs to know what version of protocol that the client is speaking and handle them accordingly, not just let client to do their job in an unexpected way.
>     
>     I don't see any elegant solutions without detecting protocol version. if you have, please describe how not being enum would avoid this.
> 
> Ivan Kelly wrote:
>     the default behaviour for an unknown error code is something we already use today.
>     https://github.com/apache/bookkeeper/blob/trunk/bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PerChannelBookieClient.java#L714
>     
>     The client only needs to know that the request failed. the point of the different error codes is so that the client could take specific recovery steps. the default behaviour is just to pass the error up.
> 
> Sijie Guo wrote:
>     the default behavior was there just for all already known status codes. but it doesn't mean it is correct for any unknown status codes. and when u are saying 'the client only needs to know that the request failed', you are making an assumption that there is only one status code indicating OK, other status code should be taken as failed. but it isn't true. say in an old protocol, we supported range reads, it responded with OK, list of entry response (0 = <data>, 1 = missing, 2 = missing, 3 = <data>). if we are going to improve our protocol to make communication more efficient, we are going to change the protocol to get rid of transferring missing entries: responding with PARTIAL_OK, list of existing entries (0 = <data>, 3 = <data>). 
>     
>     in this case, if server doesn't distinguish the client's protocol, just respond every range reads with PARTIAL_OK, would did break the compatibility with old protocol, as old protocol treats it as failure by default behavior. in order to maintain backward compatibility, server needs to detect the client's protocol and responds accordingly. as what I said, for backward compatibility, a protocol doesn't really help if it involves behavior in application agreement. and a default behavior is not exact right.
>     
>     for me, using protocol. it means that it is easy for us to add new requests type, add new fields in existing requests. besides that, we need to keep the backward compatibility in our level.
> 
> Ivan Kelly wrote:
>     when i say that 'the client only needs to know that the request failed', it means that the client only needs to recognise the statuses which indicate success. for any request, the status codes which indicate success should never change. For a read request or add request, only OK is SUCCESS. For range read,  only PARTIAL_OK and OK are success. But the client will never send a range read request unless it already knows about PARTIAL_OK.
> 
> Sijie Guo wrote:
>     > “But the client will never send a range read request unless it already knows about PARTIAL_OK.” 
>     
>     the example that I made is that the range read introduced with OK, but if it is going to evolved to have PARTIAL_OK. then that will be an problem.
> 
> Ivan Kelly wrote:
>     Partial_ok doesn't make sense if you're using the concept of packet status and operation status (as mentioned below).
> 
> Sijie Guo wrote:
>     well, if u are talking about a specific case (e.g. range read), I might agree with u. but if you read my comments, it is just the case that I explained how the protocol might be evolved. And my point is and always will be for backward compatibility, the server shouldn't send any unknown codes/fields back to clients that speaks old protocol, this is part of application-level agreement, no matter using enum or integer.
> 
> Rakesh R wrote:
>     Using enum is more readable and would be good for newcomers too. Assume a case where we are introducing new EC for an existing request type at the side server side, EC#NEW_ERR_CODE in 4.3.1 and client is old one 4.3.0. Ideally in this case, bk client should say its unknown code.
>     
>     Does this create any parsing issues at the protobuf ?. If not, I'm OK using enum for the StatusCode too.

if you read the conversation about this, my point is that for correct backward compatibility, we should avoid sending unknown error codes back to an old client.


- Sijie


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/17895/#review41130
-----------------------------------------------------------


On April 24, 2014, 7:43 a.m., Sijie Guo wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/17895/
> -----------------------------------------------------------
> 
> (Updated April 24, 2014, 7:43 a.m.)
> 
> 
> Review request for bookkeeper and Ivan Kelly.
> 
> 
> Bugs: BOOKKEEPER-582
>     https://issues.apache.org/jira/browse/BOOKKEEPER-582
> 
> 
> Repository: bookkeeper-git
> 
> 
> Description
> -------
> 
> - introducing protobuf support for bookkeeper
> - for server: introduce packet processor / EnDecoder for different protocol supports
> - for client: change PCBC to use protobuf to send requests
> - misc changes for protobuf support
> 
> (bookie server is able for backward compatibility) 
> 
> 
> Diffs
> -----
> 
>   bookkeeper-server/pom.xml ebc1198 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/bookie/IndexInMemPageMgr.java 56487aa 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/LedgerChecker.java 28e23d6 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/PendingReadOp.java fb36b90 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/processor/RequestProcessor.java 241f369 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieProtoEncoding.java 1154047 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestHandler.java b922a82 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestProcessor.java 8155b22 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookkeeperProtocol.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBase.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBaseV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PerChannelBookieClient.java a10f7d5 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/proto/BookkeeperProtocol.proto PRE-CREATION 
>   bookkeeper-server/src/main/resources/findbugsExclude.xml 97a6156 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/proto/TestProtoVersions.java 5fcc445 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/replication/AuditorPeriodicCheckTest.java 3f8496f 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/BookieClientTest.java bc05229 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/TestBackwardCompat.java 8376b46 
>   compat-deps/bookkeeper-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/hedwig-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/pom.xml f79582d 
>   hedwig-server/pom.xml 06cf01c 
>   hedwig-server/src/test/java/org/apache/hedwig/server/TestBackwardCompat.java 8da109e 
> 
> Diff: https://reviews.apache.org/r/17895/diff/
> 
> 
> Testing
> -------
> 
> unit tests. backward tests.
> 
> 
> Thanks,
> 
> Sijie Guo
> 
>

Re: Review Request 17895: BOOKKEEPER-582: protobuf support for bookkeeper

Posted by Rakesh R <ra...@huawei.com>.


> On April 23, 2014, 10:22 a.m., Ivan Kelly wrote:
> > bookkeeper-server/src/main/proto/BookkeeperProtocol.proto, line 33
> > <https://reviews.apache.org/r/17895/diff/2/?file=563033#file563033line33>
> >
> >     This should certainly not be an enum. Otherwise we need to bump the protocol version each time we add an error code.
> >     
> >     Imagine the scenario where both server and client are running 4.3.0. Then the server is upgraded with 4.3.1 which a new error EPRINTERONFIRE. It sends this to the client who throws a decode error.
> 
> Sijie Guo wrote:
>     how could being not enum help this? if it is integer, client still has no idea how to interpret, so it is still invalid response from 4.3.0 client. I thought we reached an agreement on enum on the ticket, no?
> 
> Ivan Kelly wrote:
>     So for version and operationtype, enum is ok. These originate at the client, so if the servers are always upgraded at the client, there's no interoperability issues. Status codes originate at the server though, so it is possible for the server to send a statuscode that is unrecognised to a client. The normal way to handle this would be a "else" or "default:" to pass this up to the client as a BKException.UnexpectedConditionException. If it's an enum, this will throw a decode exception in the netty decoder, which is harder to handle.
>     
>     To resolve this on the server side, by checking the version and only sending errors valid for that version, implies two things. Firstly, every error code change will require the version to be bumped and secondly, that there will need to be a list maintained for which errors are valid for each version. This goes against the motivation for using protobuf in the first place.
> 
> Sijie Guo wrote:
>     this is the application level agreement, no? it doesn't matter that u are using a protobuf protocol or using current protocol, or it also doesn't matter that u are using an integer or an enum. in any case, the best way is as you described, you shouldn't send new status code back to an old client, as the new status code is meaningless to the old client.
> 
> Ivan Kelly wrote:
>     but how do you know its an old client? Only by bumping the version number each time you add an error code. In which case you end up with a whole lot of junk like "if (client.version == X) { send A } else if (client.version == Y) { send B } else if (client.version ..." which is exactly what protobuf was designed to avoid (see "A bit of history" on https://developers.google.com/protocol-buffers/docs/overview).
> 
> Sijie Guo wrote:
>     a else or default branch would make the behavior unpredictable as an old client is treating a new status code as some kind of unknown. as you said, you want to treat them as UnexpectedConditionException. But what does UnexpectedConditionException means? doesn't it mean the sever already breaks backward compatibility, since server couldn't satisfy the old client's request.
>     
>     so still, if server wants to be backward compatibility to clients, in any cases, it needs to know what version of protocol that the client is speaking and handle them accordingly, not just let client to do their job in an unexpected way.
>     
>     I don't see any elegant solutions without detecting protocol version. if you have, please describe how not being enum would avoid this.
> 
> Ivan Kelly wrote:
>     the default behaviour for an unknown error code is something we already use today.
>     https://github.com/apache/bookkeeper/blob/trunk/bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PerChannelBookieClient.java#L714
>     
>     The client only needs to know that the request failed. the point of the different error codes is so that the client could take specific recovery steps. the default behaviour is just to pass the error up.
> 
> Sijie Guo wrote:
>     the default behavior was there just for all already known status codes. but it doesn't mean it is correct for any unknown status codes. and when u are saying 'the client only needs to know that the request failed', you are making an assumption that there is only one status code indicating OK, other status code should be taken as failed. but it isn't true. say in an old protocol, we supported range reads, it responded with OK, list of entry response (0 = <data>, 1 = missing, 2 = missing, 3 = <data>). if we are going to improve our protocol to make communication more efficient, we are going to change the protocol to get rid of transferring missing entries: responding with PARTIAL_OK, list of existing entries (0 = <data>, 3 = <data>). 
>     
>     in this case, if server doesn't distinguish the client's protocol, just respond every range reads with PARTIAL_OK, would did break the compatibility with old protocol, as old protocol treats it as failure by default behavior. in order to maintain backward compatibility, server needs to detect the client's protocol and responds accordingly. as what I said, for backward compatibility, a protocol doesn't really help if it involves behavior in application agreement. and a default behavior is not exact right.
>     
>     for me, using protocol. it means that it is easy for us to add new requests type, add new fields in existing requests. besides that, we need to keep the backward compatibility in our level.
> 
> Ivan Kelly wrote:
>     when i say that 'the client only needs to know that the request failed', it means that the client only needs to recognise the statuses which indicate success. for any request, the status codes which indicate success should never change. For a read request or add request, only OK is SUCCESS. For range read,  only PARTIAL_OK and OK are success. But the client will never send a range read request unless it already knows about PARTIAL_OK.
> 
> Sijie Guo wrote:
>     > “But the client will never send a range read request unless it already knows about PARTIAL_OK.” 
>     
>     the example that I made is that the range read introduced with OK, but if it is going to evolved to have PARTIAL_OK. then that will be an problem.
> 
> Ivan Kelly wrote:
>     Partial_ok doesn't make sense if you're using the concept of packet status and operation status (as mentioned below).
> 
> Sijie Guo wrote:
>     well, if u are talking about a specific case (e.g. range read), I might agree with u. but if you read my comments, it is just the case that I explained how the protocol might be evolved. And my point is and always will be for backward compatibility, the server shouldn't send any unknown codes/fields back to clients that speaks old protocol, this is part of application-level agreement, no matter using enum or integer.
> 
> Rakesh R wrote:
>     Using enum is more readable and would be good for newcomers too. Assume a case where we are introducing new EC for an existing request type at the side server side, EC#NEW_ERR_CODE in 4.3.1 and client is old one 4.3.0. Ideally in this case, bk client should say its unknown code.
>     
>     Does this create any parsing issues at the protobuf ?. If not, I'm OK using enum for the StatusCode too.
> 
> Sijie Guo wrote:
>     if you read the conversation about this, my point is that for correct backward compatibility, we should avoid sending unknown error codes back to an old client.
> 
> Rakesh R wrote:
>     So server should have version specific checks and generates the error codes, isn't it ?.
> 
> Sijie Guo wrote:
>     yes. exact as what I pointed. sending responses matching exact version of protocol, isn't that exactly for application level backward compatible? why this would be the concern?
> 
> Rakesh R wrote:
>     There is no big concern here. I'm trying to understand the current approach and the future path to avoid any compatibility issues later.
> 
> Sijie Guo wrote:
>     for backward compatibility, it is comprised of wire compatibility and application-semantic compatibility. using protobuf, we could easily achieve wire compatibility by adding new optional fields. for application-semantic, the server needs to detect what version of the client is talking, and send correct version of responses according to its version. the version field in the request/response structure helps achieving this.
> 
> Rakesh R wrote:
>     Maintaining version list has its own complexities, but again it depends on the client side requirements. As I know protobuf parser would not get decode exceptions if any unknown enum code comes from server, instead this will return a null value. If this is the behavior of protobuf, then today its not a blocker for this patch. Because in your patch, you have already handled unknown error code in PerChannelBookieClient#statusCodeToExceptionCode() and treats this code as an op failure.
> 
> Sijie Guo wrote:
>     version list is more for application level semantic backward compatibility. a clear specific version for backward compatibility would be more clear than any implicit solution. although it might introduce code, it is clear for maintenance.
> 
> Rakesh R wrote:
>     OK. My point is, since we have already unknown error code handling at the client side, we can discuss this case alone later. Today its not a concern for this patch, but we can atleast remember this point for future discussion :-)
>     
>     +        Integer rcToRet = statusCodeToExceptionCode(status);
>     +        if (null == rcToRet) {
>     +            rcToRet = BKException.Code.WriteException;
>     
>     +        Integer rcToRet = statusCodeToExceptionCode(status);
>     +        if (null == rcToRet) {
>     +            rcToRet = BKException.Code.ReadException;
> 
> Sijie Guo wrote:
>     what else I need to address for this? or does it mean enum works for u?

OK enum works for me.


- Rakesh


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/17895/#review41130
-----------------------------------------------------------


On April 24, 2014, 7:43 a.m., Sijie Guo wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/17895/
> -----------------------------------------------------------
> 
> (Updated April 24, 2014, 7:43 a.m.)
> 
> 
> Review request for bookkeeper and Ivan Kelly.
> 
> 
> Bugs: BOOKKEEPER-582
>     https://issues.apache.org/jira/browse/BOOKKEEPER-582
> 
> 
> Repository: bookkeeper-git
> 
> 
> Description
> -------
> 
> - introducing protobuf support for bookkeeper
> - for server: introduce packet processor / EnDecoder for different protocol supports
> - for client: change PCBC to use protobuf to send requests
> - misc changes for protobuf support
> 
> (bookie server is able for backward compatibility) 
> 
> 
> Diffs
> -----
> 
>   bookkeeper-server/pom.xml ebc1198 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/bookie/IndexInMemPageMgr.java 56487aa 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/LedgerChecker.java 28e23d6 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/PendingReadOp.java fb36b90 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/processor/RequestProcessor.java 241f369 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieProtoEncoding.java 1154047 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestHandler.java b922a82 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestProcessor.java 8155b22 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookkeeperProtocol.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBase.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBaseV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PerChannelBookieClient.java a10f7d5 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/proto/BookkeeperProtocol.proto PRE-CREATION 
>   bookkeeper-server/src/main/resources/findbugsExclude.xml 97a6156 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/proto/TestProtoVersions.java 5fcc445 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/replication/AuditorPeriodicCheckTest.java 3f8496f 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/BookieClientTest.java bc05229 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/TestBackwardCompat.java 8376b46 
>   compat-deps/bookkeeper-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/hedwig-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/pom.xml f79582d 
>   hedwig-server/pom.xml 06cf01c 
>   hedwig-server/src/test/java/org/apache/hedwig/server/TestBackwardCompat.java 8da109e 
> 
> Diff: https://reviews.apache.org/r/17895/diff/
> 
> 
> Testing
> -------
> 
> unit tests. backward tests.
> 
> 
> Thanks,
> 
> Sijie Guo
> 
>

Re: Review Request 17895: BOOKKEEPER-582: protobuf support for bookkeeper

Posted by Ivan Kelly <iv...@apache.org>.


> On April 23, 2014, 10:22 a.m., Ivan Kelly wrote:
> > bookkeeper-server/src/main/proto/BookkeeperProtocol.proto, line 80
> > <https://reviews.apache.org/r/17895/diff/2/?file=563033#file563033line80>
> >
> >     This would be better served with a boolean. protobuf will keep it compact.
> 
> Sijie Guo wrote:
>     being Flag will make it easier to add other flags in future.
> 
> Ivan Kelly wrote:
>     No it doesn't. Lets say you do add another flag in the future. How do you specify that it's both a FENCE_LEDGER and NEW_FLAG? You need the field to be repeated, and then you need code to loop through the flags. Compared to msg.isFenceLedger(), this seems much more cumbersome.
> 
> Sijie Guo wrote:
>     I don't say this field is bits-set-like of flags. as the long poll changes we mentioned, we are going to add a new flag 'ENTRY_PIGGYBACK' for read. so a read request is either a normal read (without Flag), a fence read (flag = FENCE_LEDGER) or a piggyback read (flag = ENTRY_PIGGYBACK). Being repeated will be kind of complicated, as you need to loop all possible permutation.
> 
> Ivan Kelly wrote:
>     This is ugly and shortsighted. There may well be a case in the future where two flags need to be specified. What do we do then? Add a flags2 field?
> 
> Sijie Guo wrote:
>     why this couldn't be a 3rd flag? FENCE_LEDGER_AND_PIGGYBACK?
>     
>     in your repeated way, let's say you have n flags, you would have n! ways to combine them. it is hard to figure out what kind of combination works for what situation. as some of your flags are exclusive with others. so renaming the combination specifically would make it clear.
> 
> Ivan Kelly wrote:
>     as you say, with n flags specified, there are n! combinations. so if another flag as added, you will have to add n values to the enum to cover the different combinations. whether the flags are exclusive is for the application to decide. it shouldnt be implicit in the protocol encoding.
> 
> Sijie Guo wrote:
>     same explanation for OperationType is applying here. if n flags mostly are used individually, an explicit way will just need to deal with around n possibilities. but you need to write lots of if..else branches for inferring in an implicit way.
> 
> Ivan Kelly wrote:
>     Your assumption here is that all the flag handling code will be in one place in a big switch. this isnt the case. I dont know how you have implemented piggyback, but i would guess it would be something like.
>     
>     Response processReadRequest(Request req) {
>         if (isFencing(req)) {
>             fenceLedger();
>         }
>         byte[] data = fetchEntry(req.getLedgerId(), req.getEntryId());
>         Response resp = new Response(OK, data);
>         if (isPiggyback(req)) {
>             addPiggyback(resp);
>         }
>         return resp;
>     }
>     
>     Now consider how #isPiggyback and #isFencing would be implemented with enums and with individual boolean flags? which is shorter? Which is easier to maintain?
> 
> Sijie Guo wrote:
>     isFencing => flag == Flag.FENCE_LEDGER
>     isPiggyback => flag == ENTRY_PIGGYBACK
>     
>     what is the difference above for maintaining?
>     
>     using the flag, the semantic is super clear that your request is either a fencing request or a piggyback request. it would not happen that you received a request that probably have two flags enabled, then what does it mean if the requests have two boolean flags enabled, don't consider the case (that is always the point that I made for OperationType and Flag here)? then which is easier to maintain?

my comment from yesterday doesn't wasnt saved by review board >:|

Anyhow, what i asked was, can you guarantee that there will never *ever* be a case where two flags will need to be set on a single op in the future?


- Ivan


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/17895/#review41130
-----------------------------------------------------------


On April 24, 2014, 7:43 a.m., Sijie Guo wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/17895/
> -----------------------------------------------------------
> 
> (Updated April 24, 2014, 7:43 a.m.)
> 
> 
> Review request for bookkeeper and Ivan Kelly.
> 
> 
> Bugs: BOOKKEEPER-582
>     https://issues.apache.org/jira/browse/BOOKKEEPER-582
> 
> 
> Repository: bookkeeper-git
> 
> 
> Description
> -------
> 
> - introducing protobuf support for bookkeeper
> - for server: introduce packet processor / EnDecoder for different protocol supports
> - for client: change PCBC to use protobuf to send requests
> - misc changes for protobuf support
> 
> (bookie server is able for backward compatibility) 
> 
> 
> Diffs
> -----
> 
>   bookkeeper-server/pom.xml ebc1198 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/bookie/IndexInMemPageMgr.java 56487aa 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/LedgerChecker.java 28e23d6 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/PendingReadOp.java fb36b90 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/processor/RequestProcessor.java 241f369 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieProtoEncoding.java 1154047 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestHandler.java b922a82 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestProcessor.java 8155b22 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookkeeperProtocol.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBase.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBaseV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PerChannelBookieClient.java a10f7d5 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/proto/BookkeeperProtocol.proto PRE-CREATION 
>   bookkeeper-server/src/main/resources/findbugsExclude.xml 97a6156 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/proto/TestProtoVersions.java 5fcc445 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/replication/AuditorPeriodicCheckTest.java 3f8496f 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/BookieClientTest.java bc05229 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/TestBackwardCompat.java 8376b46 
>   compat-deps/bookkeeper-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/hedwig-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/pom.xml f79582d 
>   hedwig-server/pom.xml 06cf01c 
>   hedwig-server/src/test/java/org/apache/hedwig/server/TestBackwardCompat.java 8da109e 
> 
> Diff: https://reviews.apache.org/r/17895/diff/
> 
> 
> Testing
> -------
> 
> unit tests. backward tests.
> 
> 
> Thanks,
> 
> Sijie Guo
> 
>

Re: Review Request 17895: BOOKKEEPER-582: protobuf support for bookkeeper

Posted by Rakesh R <ra...@huawei.com>.


> On April 23, 2014, 10:22 a.m., Ivan Kelly wrote:
> > bookkeeper-server/src/main/proto/BookkeeperProtocol.proto, line 33
> > <https://reviews.apache.org/r/17895/diff/2/?file=563033#file563033line33>
> >
> >     This should certainly not be an enum. Otherwise we need to bump the protocol version each time we add an error code.
> >     
> >     Imagine the scenario where both server and client are running 4.3.0. Then the server is upgraded with 4.3.1 which a new error EPRINTERONFIRE. It sends this to the client who throws a decode error.
> 
> Sijie Guo wrote:
>     how could being not enum help this? if it is integer, client still has no idea how to interpret, so it is still invalid response from 4.3.0 client. I thought we reached an agreement on enum on the ticket, no?
> 
> Ivan Kelly wrote:
>     So for version and operationtype, enum is ok. These originate at the client, so if the servers are always upgraded at the client, there's no interoperability issues. Status codes originate at the server though, so it is possible for the server to send a statuscode that is unrecognised to a client. The normal way to handle this would be a "else" or "default:" to pass this up to the client as a BKException.UnexpectedConditionException. If it's an enum, this will throw a decode exception in the netty decoder, which is harder to handle.
>     
>     To resolve this on the server side, by checking the version and only sending errors valid for that version, implies two things. Firstly, every error code change will require the version to be bumped and secondly, that there will need to be a list maintained for which errors are valid for each version. This goes against the motivation for using protobuf in the first place.
> 
> Sijie Guo wrote:
>     this is the application level agreement, no? it doesn't matter that u are using a protobuf protocol or using current protocol, or it also doesn't matter that u are using an integer or an enum. in any case, the best way is as you described, you shouldn't send new status code back to an old client, as the new status code is meaningless to the old client.
> 
> Ivan Kelly wrote:
>     but how do you know its an old client? Only by bumping the version number each time you add an error code. In which case you end up with a whole lot of junk like "if (client.version == X) { send A } else if (client.version == Y) { send B } else if (client.version ..." which is exactly what protobuf was designed to avoid (see "A bit of history" on https://developers.google.com/protocol-buffers/docs/overview).
> 
> Sijie Guo wrote:
>     a else or default branch would make the behavior unpredictable as an old client is treating a new status code as some kind of unknown. as you said, you want to treat them as UnexpectedConditionException. But what does UnexpectedConditionException means? doesn't it mean the sever already breaks backward compatibility, since server couldn't satisfy the old client's request.
>     
>     so still, if server wants to be backward compatibility to clients, in any cases, it needs to know what version of protocol that the client is speaking and handle them accordingly, not just let client to do their job in an unexpected way.
>     
>     I don't see any elegant solutions without detecting protocol version. if you have, please describe how not being enum would avoid this.
> 
> Ivan Kelly wrote:
>     the default behaviour for an unknown error code is something we already use today.
>     https://github.com/apache/bookkeeper/blob/trunk/bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PerChannelBookieClient.java#L714
>     
>     The client only needs to know that the request failed. the point of the different error codes is so that the client could take specific recovery steps. the default behaviour is just to pass the error up.
> 
> Sijie Guo wrote:
>     the default behavior was there just for all already known status codes. but it doesn't mean it is correct for any unknown status codes. and when u are saying 'the client only needs to know that the request failed', you are making an assumption that there is only one status code indicating OK, other status code should be taken as failed. but it isn't true. say in an old protocol, we supported range reads, it responded with OK, list of entry response (0 = <data>, 1 = missing, 2 = missing, 3 = <data>). if we are going to improve our protocol to make communication more efficient, we are going to change the protocol to get rid of transferring missing entries: responding with PARTIAL_OK, list of existing entries (0 = <data>, 3 = <data>). 
>     
>     in this case, if server doesn't distinguish the client's protocol, just respond every range reads with PARTIAL_OK, would did break the compatibility with old protocol, as old protocol treats it as failure by default behavior. in order to maintain backward compatibility, server needs to detect the client's protocol and responds accordingly. as what I said, for backward compatibility, a protocol doesn't really help if it involves behavior in application agreement. and a default behavior is not exact right.
>     
>     for me, using protocol. it means that it is easy for us to add new requests type, add new fields in existing requests. besides that, we need to keep the backward compatibility in our level.
> 
> Ivan Kelly wrote:
>     when i say that 'the client only needs to know that the request failed', it means that the client only needs to recognise the statuses which indicate success. for any request, the status codes which indicate success should never change. For a read request or add request, only OK is SUCCESS. For range read,  only PARTIAL_OK and OK are success. But the client will never send a range read request unless it already knows about PARTIAL_OK.
> 
> Sijie Guo wrote:
>     > “But the client will never send a range read request unless it already knows about PARTIAL_OK.” 
>     
>     the example that I made is that the range read introduced with OK, but if it is going to evolved to have PARTIAL_OK. then that will be an problem.
> 
> Ivan Kelly wrote:
>     Partial_ok doesn't make sense if you're using the concept of packet status and operation status (as mentioned below).
> 
> Sijie Guo wrote:
>     well, if u are talking about a specific case (e.g. range read), I might agree with u. but if you read my comments, it is just the case that I explained how the protocol might be evolved. And my point is and always will be for backward compatibility, the server shouldn't send any unknown codes/fields back to clients that speaks old protocol, this is part of application-level agreement, no matter using enum or integer.

Using enum is more readable and would be good for newcomers too. Assume a case where we are introducing new EC for an existing request type at the side server side, EC#NEW_ERR_CODE in 4.3.1 and client is old one 4.3.0. Ideally in this case, bk client should say its unknown code.

Does this create any parsing issues at the protobuf ?. If not, I'm OK using enum for the StatusCode too.


- Rakesh


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/17895/#review41130
-----------------------------------------------------------


On April 24, 2014, 7:43 a.m., Sijie Guo wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/17895/
> -----------------------------------------------------------
> 
> (Updated April 24, 2014, 7:43 a.m.)
> 
> 
> Review request for bookkeeper and Ivan Kelly.
> 
> 
> Bugs: BOOKKEEPER-582
>     https://issues.apache.org/jira/browse/BOOKKEEPER-582
> 
> 
> Repository: bookkeeper-git
> 
> 
> Description
> -------
> 
> - introducing protobuf support for bookkeeper
> - for server: introduce packet processor / EnDecoder for different protocol supports
> - for client: change PCBC to use protobuf to send requests
> - misc changes for protobuf support
> 
> (bookie server is able for backward compatibility) 
> 
> 
> Diffs
> -----
> 
>   bookkeeper-server/pom.xml ebc1198 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/bookie/IndexInMemPageMgr.java 56487aa 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/LedgerChecker.java 28e23d6 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/PendingReadOp.java fb36b90 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/processor/RequestProcessor.java 241f369 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieProtoEncoding.java 1154047 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestHandler.java b922a82 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestProcessor.java 8155b22 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookkeeperProtocol.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBase.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBaseV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PerChannelBookieClient.java a10f7d5 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/proto/BookkeeperProtocol.proto PRE-CREATION 
>   bookkeeper-server/src/main/resources/findbugsExclude.xml 97a6156 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/proto/TestProtoVersions.java 5fcc445 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/replication/AuditorPeriodicCheckTest.java 3f8496f 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/BookieClientTest.java bc05229 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/TestBackwardCompat.java 8376b46 
>   compat-deps/bookkeeper-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/hedwig-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/pom.xml f79582d 
>   hedwig-server/pom.xml 06cf01c 
>   hedwig-server/src/test/java/org/apache/hedwig/server/TestBackwardCompat.java 8da109e 
> 
> Diff: https://reviews.apache.org/r/17895/diff/
> 
> 
> Testing
> -------
> 
> unit tests. backward tests.
> 
> 
> Thanks,
> 
> Sijie Guo
> 
>

Re: Review Request 17895: BOOKKEEPER-582: protobuf support for bookkeeper

Posted by Sijie Guo <gu...@gmail.com>.


> On April 23, 2014, 10:22 a.m., Ivan Kelly wrote:
> > bookkeeper-server/src/main/proto/BookkeeperProtocol.proto, line 80
> > <https://reviews.apache.org/r/17895/diff/2/?file=563033#file563033line80>
> >
> >     This would be better served with a boolean. protobuf will keep it compact.
> 
> Sijie Guo wrote:
>     being Flag will make it easier to add other flags in future.
> 
> Ivan Kelly wrote:
>     No it doesn't. Lets say you do add another flag in the future. How do you specify that it's both a FENCE_LEDGER and NEW_FLAG? You need the field to be repeated, and then you need code to loop through the flags. Compared to msg.isFenceLedger(), this seems much more cumbersome.
> 
> Sijie Guo wrote:
>     I don't say this field is bits-set-like of flags. as the long poll changes we mentioned, we are going to add a new flag 'ENTRY_PIGGYBACK' for read. so a read request is either a normal read (without Flag), a fence read (flag = FENCE_LEDGER) or a piggyback read (flag = ENTRY_PIGGYBACK). Being repeated will be kind of complicated, as you need to loop all possible permutation.
> 
> Ivan Kelly wrote:
>     This is ugly and shortsighted. There may well be a case in the future where two flags need to be specified. What do we do then? Add a flags2 field?
> 
> Sijie Guo wrote:
>     why this couldn't be a 3rd flag? FENCE_LEDGER_AND_PIGGYBACK?
>     
>     in your repeated way, let's say you have n flags, you would have n! ways to combine them. it is hard to figure out what kind of combination works for what situation. as some of your flags are exclusive with others. so renaming the combination specifically would make it clear.
> 
> Ivan Kelly wrote:
>     as you say, with n flags specified, there are n! combinations. so if another flag as added, you will have to add n values to the enum to cover the different combinations. whether the flags are exclusive is for the application to decide. it shouldnt be implicit in the protocol encoding.
> 
> Sijie Guo wrote:
>     same explanation for OperationType is applying here. if n flags mostly are used individually, an explicit way will just need to deal with around n possibilities. but you need to write lots of if..else branches for inferring in an implicit way.
> 
> Ivan Kelly wrote:
>     Your assumption here is that all the flag handling code will be in one place in a big switch. this isnt the case. I dont know how you have implemented piggyback, but i would guess it would be something like.
>     
>     Response processReadRequest(Request req) {
>         if (isFencing(req)) {
>             fenceLedger();
>         }
>         byte[] data = fetchEntry(req.getLedgerId(), req.getEntryId());
>         Response resp = new Response(OK, data);
>         if (isPiggyback(req)) {
>             addPiggyback(resp);
>         }
>         return resp;
>     }
>     
>     Now consider how #isPiggyback and #isFencing would be implemented with enums and with individual boolean flags? which is shorter? Which is easier to maintain?
> 
> Sijie Guo wrote:
>     isFencing => flag == Flag.FENCE_LEDGER
>     isPiggyback => flag == ENTRY_PIGGYBACK
>     
>     what is the difference above for maintaining?
>     
>     using the flag, the semantic is super clear that your request is either a fencing request or a piggyback request. it would not happen that you received a request that probably have two flags enabled, then what does it mean if the requests have two boolean flags enabled, don't consider the case (that is always the point that I made for OperationType and Flag here)? then which is easier to maintain?
> 
> Ivan Kelly wrote:
>     my comment from yesterday doesn't wasnt saved by review board >:|
>     
>     Anyhow, what i asked was, can you guarantee that there will never *ever* be a case where two flags will need to be set on a single op in the future?
> 
> Sijie Guo wrote:
>     well, I already made a comment on your case: "why this couldn't be a 3rd flag? FENCE_LEDGER_AND_PIGGYBACK?", no? and this is how hedwig handles subscription mode, 'create', 'attach', 'create_and_attach', no?
>     
>     and again, as I said in previous comment, if you define flags in an explicit way, you would have much clearer branches on what kind of operations should be executed on what flags, like below: (take an example, A, B, C, A_AND_B, B_AND_A)
>     
>     switch (flag) {
>     case A:
>       a();
>       break;
>     case B:
>       b();
>       break;
>     case C:
>       c();
>       break;
>     case A_AND_B:
>       a();
>       b();
>       break;
>     case B_AND_A:
>       b();
>       // other executions between b() and a(), which is different from A_AND_B case.
>       a();
>       break;
>     }
>     
>     but if you define flags in an implicit way, you need to check all possible negative cases to avoid the program failed in abnormal cases (e.g. bad combinations, bad order of flags). isn't that introducing much harder work for maintenance? 
>
> 
> Rakesh R wrote:
>     If we have a set of flags, also consider both AND/OR conjunctions the combinations may grow and thus increases the complexity of the problem. I feel it doesn't matter whether you are using enum type or bool flag, both will have 'chain of if conditions' either at the client side or at the server side. If I understood correctly the switch case you are talking will be added at the server side. Now for setting 'A_AND_B' enum type in the request, client side we need to have the 'chain of if conditions' no?.
>     
>     I could see few advantages of having 'if chain' at the client side, server would not worry about the conditional evaluation which may be in a critical section. Secondly it would be easy to define strategies against enum type and pass it over different layers without worrying about how they formed.
>     
>     If we think the problem space is small and assume we have only few set of flags I prefer enum. Before reaching to a conclusion I've one question about the number 'n' of flags and how much value 'n' can grow ?. Only my worry is, once we set the protocol to enum type, as we all know couldn't get another chance to change it later as 'n' increases.

> Now for setting 'A_AND_B' enum type in the request, client side we need to have the 'chain of if conditions' no?.

why client need to have the chain? client just need to set different flag value to indicate different type of single read. 

>  how much value 'n' can grow?

I could tell the future. but I don't see it would grow too much. A specific enum value would make semantic more clear.


> On April 23, 2014, 10:22 a.m., Ivan Kelly wrote:
> > bookkeeper-server/src/main/proto/BookkeeperProtocol.proto, line 33
> > <https://reviews.apache.org/r/17895/diff/2/?file=563033#file563033line33>
> >
> >     This should certainly not be an enum. Otherwise we need to bump the protocol version each time we add an error code.
> >     
> >     Imagine the scenario where both server and client are running 4.3.0. Then the server is upgraded with 4.3.1 which a new error EPRINTERONFIRE. It sends this to the client who throws a decode error.
> 
> Sijie Guo wrote:
>     how could being not enum help this? if it is integer, client still has no idea how to interpret, so it is still invalid response from 4.3.0 client. I thought we reached an agreement on enum on the ticket, no?
> 
> Ivan Kelly wrote:
>     So for version and operationtype, enum is ok. These originate at the client, so if the servers are always upgraded at the client, there's no interoperability issues. Status codes originate at the server though, so it is possible for the server to send a statuscode that is unrecognised to a client. The normal way to handle this would be a "else" or "default:" to pass this up to the client as a BKException.UnexpectedConditionException. If it's an enum, this will throw a decode exception in the netty decoder, which is harder to handle.
>     
>     To resolve this on the server side, by checking the version and only sending errors valid for that version, implies two things. Firstly, every error code change will require the version to be bumped and secondly, that there will need to be a list maintained for which errors are valid for each version. This goes against the motivation for using protobuf in the first place.
> 
> Sijie Guo wrote:
>     this is the application level agreement, no? it doesn't matter that u are using a protobuf protocol or using current protocol, or it also doesn't matter that u are using an integer or an enum. in any case, the best way is as you described, you shouldn't send new status code back to an old client, as the new status code is meaningless to the old client.
> 
> Ivan Kelly wrote:
>     but how do you know its an old client? Only by bumping the version number each time you add an error code. In which case you end up with a whole lot of junk like "if (client.version == X) { send A } else if (client.version == Y) { send B } else if (client.version ..." which is exactly what protobuf was designed to avoid (see "A bit of history" on https://developers.google.com/protocol-buffers/docs/overview).
> 
> Sijie Guo wrote:
>     a else or default branch would make the behavior unpredictable as an old client is treating a new status code as some kind of unknown. as you said, you want to treat them as UnexpectedConditionException. But what does UnexpectedConditionException means? doesn't it mean the sever already breaks backward compatibility, since server couldn't satisfy the old client's request.
>     
>     so still, if server wants to be backward compatibility to clients, in any cases, it needs to know what version of protocol that the client is speaking and handle them accordingly, not just let client to do their job in an unexpected way.
>     
>     I don't see any elegant solutions without detecting protocol version. if you have, please describe how not being enum would avoid this.
> 
> Ivan Kelly wrote:
>     the default behaviour for an unknown error code is something we already use today.
>     https://github.com/apache/bookkeeper/blob/trunk/bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PerChannelBookieClient.java#L714
>     
>     The client only needs to know that the request failed. the point of the different error codes is so that the client could take specific recovery steps. the default behaviour is just to pass the error up.
> 
> Sijie Guo wrote:
>     the default behavior was there just for all already known status codes. but it doesn't mean it is correct for any unknown status codes. and when u are saying 'the client only needs to know that the request failed', you are making an assumption that there is only one status code indicating OK, other status code should be taken as failed. but it isn't true. say in an old protocol, we supported range reads, it responded with OK, list of entry response (0 = <data>, 1 = missing, 2 = missing, 3 = <data>). if we are going to improve our protocol to make communication more efficient, we are going to change the protocol to get rid of transferring missing entries: responding with PARTIAL_OK, list of existing entries (0 = <data>, 3 = <data>). 
>     
>     in this case, if server doesn't distinguish the client's protocol, just respond every range reads with PARTIAL_OK, would did break the compatibility with old protocol, as old protocol treats it as failure by default behavior. in order to maintain backward compatibility, server needs to detect the client's protocol and responds accordingly. as what I said, for backward compatibility, a protocol doesn't really help if it involves behavior in application agreement. and a default behavior is not exact right.
>     
>     for me, using protocol. it means that it is easy for us to add new requests type, add new fields in existing requests. besides that, we need to keep the backward compatibility in our level.
> 
> Ivan Kelly wrote:
>     when i say that 'the client only needs to know that the request failed', it means that the client only needs to recognise the statuses which indicate success. for any request, the status codes which indicate success should never change. For a read request or add request, only OK is SUCCESS. For range read,  only PARTIAL_OK and OK are success. But the client will never send a range read request unless it already knows about PARTIAL_OK.
> 
> Sijie Guo wrote:
>     > “But the client will never send a range read request unless it already knows about PARTIAL_OK.” 
>     
>     the example that I made is that the range read introduced with OK, but if it is going to evolved to have PARTIAL_OK. then that will be an problem.
> 
> Ivan Kelly wrote:
>     Partial_ok doesn't make sense if you're using the concept of packet status and operation status (as mentioned below).
> 
> Sijie Guo wrote:
>     well, if u are talking about a specific case (e.g. range read), I might agree with u. but if you read my comments, it is just the case that I explained how the protocol might be evolved. And my point is and always will be for backward compatibility, the server shouldn't send any unknown codes/fields back to clients that speaks old protocol, this is part of application-level agreement, no matter using enum or integer.
> 
> Rakesh R wrote:
>     Using enum is more readable and would be good for newcomers too. Assume a case where we are introducing new EC for an existing request type at the side server side, EC#NEW_ERR_CODE in 4.3.1 and client is old one 4.3.0. Ideally in this case, bk client should say its unknown code.
>     
>     Does this create any parsing issues at the protobuf ?. If not, I'm OK using enum for the StatusCode too.
> 
> Sijie Guo wrote:
>     if you read the conversation about this, my point is that for correct backward compatibility, we should avoid sending unknown error codes back to an old client.
> 
> Rakesh R wrote:
>     So server should have version specific checks and generates the error codes, isn't it ?.
> 
> Sijie Guo wrote:
>     yes. exact as what I pointed. sending responses matching exact version of protocol, isn't that exactly for application level backward compatible? why this would be the concern?
> 
> Rakesh R wrote:
>     There is no big concern here. I'm trying to understand the current approach and the future path to avoid any compatibility issues later.
> 
> Sijie Guo wrote:
>     for backward compatibility, it is comprised of wire compatibility and application-semantic compatibility. using protobuf, we could easily achieve wire compatibility by adding new optional fields. for application-semantic, the server needs to detect what version of the client is talking, and send correct version of responses according to its version. the version field in the request/response structure helps achieving this.
> 
> Rakesh R wrote:
>     Maintaining version list has its own complexities, but again it depends on the client side requirements. As I know protobuf parser would not get decode exceptions if any unknown enum code comes from server, instead this will return a null value. If this is the behavior of protobuf, then today its not a blocker for this patch. Because in your patch, you have already handled unknown error code in PerChannelBookieClient#statusCodeToExceptionCode() and treats this code as an op failure.

version list is more for application level semantic backward compatibility. a clear specific version for backward compatibility would be more clear than any implicit solution. although it might introduce code, it is clear for maintenance.


- Sijie


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/17895/#review41130
-----------------------------------------------------------


On April 24, 2014, 7:43 a.m., Sijie Guo wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/17895/
> -----------------------------------------------------------
> 
> (Updated April 24, 2014, 7:43 a.m.)
> 
> 
> Review request for bookkeeper and Ivan Kelly.
> 
> 
> Bugs: BOOKKEEPER-582
>     https://issues.apache.org/jira/browse/BOOKKEEPER-582
> 
> 
> Repository: bookkeeper-git
> 
> 
> Description
> -------
> 
> - introducing protobuf support for bookkeeper
> - for server: introduce packet processor / EnDecoder for different protocol supports
> - for client: change PCBC to use protobuf to send requests
> - misc changes for protobuf support
> 
> (bookie server is able for backward compatibility) 
> 
> 
> Diffs
> -----
> 
>   bookkeeper-server/pom.xml ebc1198 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/bookie/IndexInMemPageMgr.java 56487aa 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/LedgerChecker.java 28e23d6 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/PendingReadOp.java fb36b90 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/processor/RequestProcessor.java 241f369 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieProtoEncoding.java 1154047 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestHandler.java b922a82 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestProcessor.java 8155b22 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookkeeperProtocol.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBase.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBaseV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PerChannelBookieClient.java a10f7d5 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/proto/BookkeeperProtocol.proto PRE-CREATION 
>   bookkeeper-server/src/main/resources/findbugsExclude.xml 97a6156 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/proto/TestProtoVersions.java 5fcc445 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/replication/AuditorPeriodicCheckTest.java 3f8496f 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/BookieClientTest.java bc05229 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/TestBackwardCompat.java 8376b46 
>   compat-deps/bookkeeper-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/hedwig-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/pom.xml f79582d 
>   hedwig-server/pom.xml 06cf01c 
>   hedwig-server/src/test/java/org/apache/hedwig/server/TestBackwardCompat.java 8da109e 
> 
> Diff: https://reviews.apache.org/r/17895/diff/
> 
> 
> Testing
> -------
> 
> unit tests. backward tests.
> 
> 
> Thanks,
> 
> Sijie Guo
> 
>

Re: Review Request 17895: BOOKKEEPER-582: protobuf support for bookkeeper

Posted by Sijie Guo <gu...@gmail.com>.


> On April 23, 2014, 10:22 a.m., Ivan Kelly wrote:
> > bookkeeper-server/src/main/proto/BookkeeperProtocol.proto, line 33
> > <https://reviews.apache.org/r/17895/diff/2/?file=563033#file563033line33>
> >
> >     This should certainly not be an enum. Otherwise we need to bump the protocol version each time we add an error code.
> >     
> >     Imagine the scenario where both server and client are running 4.3.0. Then the server is upgraded with 4.3.1 which a new error EPRINTERONFIRE. It sends this to the client who throws a decode error.
> 
> Sijie Guo wrote:
>     how could being not enum help this? if it is integer, client still has no idea how to interpret, so it is still invalid response from 4.3.0 client. I thought we reached an agreement on enum on the ticket, no?
> 
> Ivan Kelly wrote:
>     So for version and operationtype, enum is ok. These originate at the client, so if the servers are always upgraded at the client, there's no interoperability issues. Status codes originate at the server though, so it is possible for the server to send a statuscode that is unrecognised to a client. The normal way to handle this would be a "else" or "default:" to pass this up to the client as a BKException.UnexpectedConditionException. If it's an enum, this will throw a decode exception in the netty decoder, which is harder to handle.
>     
>     To resolve this on the server side, by checking the version and only sending errors valid for that version, implies two things. Firstly, every error code change will require the version to be bumped and secondly, that there will need to be a list maintained for which errors are valid for each version. This goes against the motivation for using protobuf in the first place.
> 
> Sijie Guo wrote:
>     this is the application level agreement, no? it doesn't matter that u are using a protobuf protocol or using current protocol, or it also doesn't matter that u are using an integer or an enum. in any case, the best way is as you described, you shouldn't send new status code back to an old client, as the new status code is meaningless to the old client.
> 
> Ivan Kelly wrote:
>     but how do you know its an old client? Only by bumping the version number each time you add an error code. In which case you end up with a whole lot of junk like "if (client.version == X) { send A } else if (client.version == Y) { send B } else if (client.version ..." which is exactly what protobuf was designed to avoid (see "A bit of history" on https://developers.google.com/protocol-buffers/docs/overview).
> 
> Sijie Guo wrote:
>     a else or default branch would make the behavior unpredictable as an old client is treating a new status code as some kind of unknown. as you said, you want to treat them as UnexpectedConditionException. But what does UnexpectedConditionException means? doesn't it mean the sever already breaks backward compatibility, since server couldn't satisfy the old client's request.
>     
>     so still, if server wants to be backward compatibility to clients, in any cases, it needs to know what version of protocol that the client is speaking and handle them accordingly, not just let client to do their job in an unexpected way.
>     
>     I don't see any elegant solutions without detecting protocol version. if you have, please describe how not being enum would avoid this.
> 
> Ivan Kelly wrote:
>     the default behaviour for an unknown error code is something we already use today.
>     https://github.com/apache/bookkeeper/blob/trunk/bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PerChannelBookieClient.java#L714
>     
>     The client only needs to know that the request failed. the point of the different error codes is so that the client could take specific recovery steps. the default behaviour is just to pass the error up.
> 
> Sijie Guo wrote:
>     the default behavior was there just for all already known status codes. but it doesn't mean it is correct for any unknown status codes. and when u are saying 'the client only needs to know that the request failed', you are making an assumption that there is only one status code indicating OK, other status code should be taken as failed. but it isn't true. say in an old protocol, we supported range reads, it responded with OK, list of entry response (0 = <data>, 1 = missing, 2 = missing, 3 = <data>). if we are going to improve our protocol to make communication more efficient, we are going to change the protocol to get rid of transferring missing entries: responding with PARTIAL_OK, list of existing entries (0 = <data>, 3 = <data>). 
>     
>     in this case, if server doesn't distinguish the client's protocol, just respond every range reads with PARTIAL_OK, would did break the compatibility with old protocol, as old protocol treats it as failure by default behavior. in order to maintain backward compatibility, server needs to detect the client's protocol and responds accordingly. as what I said, for backward compatibility, a protocol doesn't really help if it involves behavior in application agreement. and a default behavior is not exact right.
>     
>     for me, using protocol. it means that it is easy for us to add new requests type, add new fields in existing requests. besides that, we need to keep the backward compatibility in our level.
> 
> Ivan Kelly wrote:
>     when i say that 'the client only needs to know that the request failed', it means that the client only needs to recognise the statuses which indicate success. for any request, the status codes which indicate success should never change. For a read request or add request, only OK is SUCCESS. For range read,  only PARTIAL_OK and OK are success. But the client will never send a range read request unless it already knows about PARTIAL_OK.
> 
> Sijie Guo wrote:
>     > “But the client will never send a range read request unless it already knows about PARTIAL_OK.” 
>     
>     the example that I made is that the range read introduced with OK, but if it is going to evolved to have PARTIAL_OK. then that will be an problem.
> 
> Ivan Kelly wrote:
>     Partial_ok doesn't make sense if you're using the concept of packet status and operation status (as mentioned below).

well, if u are talking about a specific case (e.g. range read), I might agree with u. but if you read my comments, it is just the case that I explained how the protocol might be evolved. And my point is and always will be for backward compatibility, the server shouldn't send any unknown codes/fields back to clients that speaks old protocol, this is part of application-level agreement, no matter using enum or integer.


> On April 23, 2014, 10:22 a.m., Ivan Kelly wrote:
> > bookkeeper-server/src/main/proto/BookkeeperProtocol.proto, line 104
> > <https://reviews.apache.org/r/17895/diff/2/?file=563033#file563033line104>
> >
> >     You're sending StatusCode twice, every time. Firstly, shouldn't be an enum as stated above. Secondly, shouldn't be required.
> 
> Sijie Guo wrote:
>     > enum
>     
>     as the comments above.
>     
>     > status code twice.
>     
>     the status code for ReadResponse/AddResponse is for individual responses. if we are going to support kind of batch reads, the status code of Response means either the whole batch succeed or not while the individual read responses might have different status codes (e.g OK or NotExists). That is why it exists two places.
>     
>     > required
>     
>     as the comments above
> 
> Ivan Kelly wrote:
>     Per request makes sense. However, in that case, can't you just remove the per packet status?
> 
> Sijie Guo wrote:
>     Nope. the packet status indicates whether the packet succeed or not. say if it is batch read, if the total batch read failed, it would set the whole packet status to be failed and there would be no individual responses in the packet since the whole batch failed.
> 
> Ivan Kelly wrote:
>     Then it should have a different name. Like entryStatus & packetStatus. But then you also have a consistency problem. What is packetStatus is OK, but one entryStatus is an error? Will there be a SOME_OK error? In what scenario would a whole read batch fail?
> 
> Sijie Guo wrote:
>     if ledger isn't exists, then a packet status with NoSuchLedgerExists is returned. if ledger exists, but some entries are missing, so ok is returned for the packet, but NoSuchEntry would be returned for the missing entries.
> 
> Ivan Kelly wrote:
>     this would be better handled with a batch intermediatory message, defined like
>     
>     message Response {
>         required BKPacketHeader header = 1;
>     
>         optional ReadResponse readResponse = 100;
>         optional AddResponse addResponse = 101;
>         optional BatchReadResponse batchReadResponse = 102;
>     }
>     
>     message ReadResponse {
>         required StatusCode status = 1;
>         required int64 ledgerId = 2;
>         required int64 entryId = 3;
>         optional bytes body = 4;
>     }
>     
>     message BatchReadResponse {
>         optional StatusCode status = 1;
>         repeated ReadResponse entries = 2;
>     }
>     
>     message AddResponse {
>         required StatusCode status = 1;
>         required int64 ledgerId = 2;
>         required int64 entryId = 3;
>     }
>
> 
> Sijie Guo wrote:
>     the point of differentiating the status code in packet from the one in operations. there are common status codes which are in packet level not related to individual operations, like 'bad request', 'authentication failure' etc, in this case they could be handled in packet level rather than operations level. otherwise, you need to add duplicated logic to handle those common things in operation responses each time you added new type of requests. doesn't this make a call for separating packet status from operation status?
> 
> Ivan Kelly wrote:
>     >  otherwise, you need to add duplicated logic to handle those common things in operation responses each time you added new type of requests.
>     You have duplicate logic here anyhow. (PerChannelBookieClient.java:633)
>     It does make some sense to have a packet level status and an op level status. But then they shouldn't share codes. StatusCode should be split into PacketStatusCode and OpStatusCode.

the duplicate logic there is somehow for the difference of callback signatures. but it is easy to tweak the implementation to extract common logic if we have package status code and operation status code there. The reason the we have single set of status code, is that we could easily map the status code back to callback result code.


- Sijie


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/17895/#review41130
-----------------------------------------------------------


On April 24, 2014, 7:43 a.m., Sijie Guo wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/17895/
> -----------------------------------------------------------
> 
> (Updated April 24, 2014, 7:43 a.m.)
> 
> 
> Review request for bookkeeper and Ivan Kelly.
> 
> 
> Bugs: BOOKKEEPER-582
>     https://issues.apache.org/jira/browse/BOOKKEEPER-582
> 
> 
> Repository: bookkeeper-git
> 
> 
> Description
> -------
> 
> - introducing protobuf support for bookkeeper
> - for server: introduce packet processor / EnDecoder for different protocol supports
> - for client: change PCBC to use protobuf to send requests
> - misc changes for protobuf support
> 
> (bookie server is able for backward compatibility) 
> 
> 
> Diffs
> -----
> 
>   bookkeeper-server/pom.xml ebc1198 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/bookie/IndexInMemPageMgr.java 56487aa 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/LedgerChecker.java 28e23d6 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/PendingReadOp.java fb36b90 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/processor/RequestProcessor.java 241f369 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieProtoEncoding.java 1154047 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestHandler.java b922a82 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestProcessor.java 8155b22 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookkeeperProtocol.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBase.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBaseV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PerChannelBookieClient.java a10f7d5 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/proto/BookkeeperProtocol.proto PRE-CREATION 
>   bookkeeper-server/src/main/resources/findbugsExclude.xml 97a6156 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/proto/TestProtoVersions.java 5fcc445 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/replication/AuditorPeriodicCheckTest.java 3f8496f 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/BookieClientTest.java bc05229 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/TestBackwardCompat.java 8376b46 
>   compat-deps/bookkeeper-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/hedwig-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/pom.xml f79582d 
>   hedwig-server/pom.xml 06cf01c 
>   hedwig-server/src/test/java/org/apache/hedwig/server/TestBackwardCompat.java 8da109e 
> 
> Diff: https://reviews.apache.org/r/17895/diff/
> 
> 
> Testing
> -------
> 
> unit tests. backward tests.
> 
> 
> Thanks,
> 
> Sijie Guo
> 
>

Re: Review Request 17895: BOOKKEEPER-582: protobuf support for bookkeeper

Posted by Rakesh R <ra...@huawei.com>.


> On April 23, 2014, 10:22 a.m., Ivan Kelly wrote:
> > bookkeeper-server/src/main/proto/BookkeeperProtocol.proto, line 80
> > <https://reviews.apache.org/r/17895/diff/2/?file=563033#file563033line80>
> >
> >     This would be better served with a boolean. protobuf will keep it compact.
> 
> Sijie Guo wrote:
>     being Flag will make it easier to add other flags in future.
> 
> Ivan Kelly wrote:
>     No it doesn't. Lets say you do add another flag in the future. How do you specify that it's both a FENCE_LEDGER and NEW_FLAG? You need the field to be repeated, and then you need code to loop through the flags. Compared to msg.isFenceLedger(), this seems much more cumbersome.
> 
> Sijie Guo wrote:
>     I don't say this field is bits-set-like of flags. as the long poll changes we mentioned, we are going to add a new flag 'ENTRY_PIGGYBACK' for read. so a read request is either a normal read (without Flag), a fence read (flag = FENCE_LEDGER) or a piggyback read (flag = ENTRY_PIGGYBACK). Being repeated will be kind of complicated, as you need to loop all possible permutation.
> 
> Ivan Kelly wrote:
>     This is ugly and shortsighted. There may well be a case in the future where two flags need to be specified. What do we do then? Add a flags2 field?
> 
> Sijie Guo wrote:
>     why this couldn't be a 3rd flag? FENCE_LEDGER_AND_PIGGYBACK?
>     
>     in your repeated way, let's say you have n flags, you would have n! ways to combine them. it is hard to figure out what kind of combination works for what situation. as some of your flags are exclusive with others. so renaming the combination specifically would make it clear.
> 
> Ivan Kelly wrote:
>     as you say, with n flags specified, there are n! combinations. so if another flag as added, you will have to add n values to the enum to cover the different combinations. whether the flags are exclusive is for the application to decide. it shouldnt be implicit in the protocol encoding.
> 
> Sijie Guo wrote:
>     same explanation for OperationType is applying here. if n flags mostly are used individually, an explicit way will just need to deal with around n possibilities. but you need to write lots of if..else branches for inferring in an implicit way.
> 
> Ivan Kelly wrote:
>     Your assumption here is that all the flag handling code will be in one place in a big switch. this isnt the case. I dont know how you have implemented piggyback, but i would guess it would be something like.
>     
>     Response processReadRequest(Request req) {
>         if (isFencing(req)) {
>             fenceLedger();
>         }
>         byte[] data = fetchEntry(req.getLedgerId(), req.getEntryId());
>         Response resp = new Response(OK, data);
>         if (isPiggyback(req)) {
>             addPiggyback(resp);
>         }
>         return resp;
>     }
>     
>     Now consider how #isPiggyback and #isFencing would be implemented with enums and with individual boolean flags? which is shorter? Which is easier to maintain?
> 
> Sijie Guo wrote:
>     isFencing => flag == Flag.FENCE_LEDGER
>     isPiggyback => flag == ENTRY_PIGGYBACK
>     
>     what is the difference above for maintaining?
>     
>     using the flag, the semantic is super clear that your request is either a fencing request or a piggyback request. it would not happen that you received a request that probably have two flags enabled, then what does it mean if the requests have two boolean flags enabled, don't consider the case (that is always the point that I made for OperationType and Flag here)? then which is easier to maintain?
> 
> Ivan Kelly wrote:
>     my comment from yesterday doesn't wasnt saved by review board >:|
>     
>     Anyhow, what i asked was, can you guarantee that there will never *ever* be a case where two flags will need to be set on a single op in the future?
> 
> Sijie Guo wrote:
>     well, I already made a comment on your case: "why this couldn't be a 3rd flag? FENCE_LEDGER_AND_PIGGYBACK?", no? and this is how hedwig handles subscription mode, 'create', 'attach', 'create_and_attach', no?
>     
>     and again, as I said in previous comment, if you define flags in an explicit way, you would have much clearer branches on what kind of operations should be executed on what flags, like below: (take an example, A, B, C, A_AND_B, B_AND_A)
>     
>     switch (flag) {
>     case A:
>       a();
>       break;
>     case B:
>       b();
>       break;
>     case C:
>       c();
>       break;
>     case A_AND_B:
>       a();
>       b();
>       break;
>     case B_AND_A:
>       b();
>       // other executions between b() and a(), which is different from A_AND_B case.
>       a();
>       break;
>     }
>     
>     but if you define flags in an implicit way, you need to check all possible negative cases to avoid the program failed in abnormal cases (e.g. bad combinations, bad order of flags). isn't that introducing much harder work for maintenance? 
>

If we have a set of flags, also consider both AND/OR conjunctions the combinations may grow and thus increases the complexity of the problem. I feel it doesn't matter whether you are using enum type or bool flag, both will have 'chain of if conditions' either at the client side or at the server side. If I understood correctly the switch case you are talking will be added at the server side. Now for setting 'A_AND_B' enum type in the request, client side we need to have the 'chain of if conditions' no?.

I could see few advantages of having 'if chain' at the client side, server would not worry about the conditional evaluation which may be in a critical section. Secondly it would be easy to define strategies against enum type and pass it over different layers without worrying about how they formed.

If we think the problem space is small and assume we have only few set of flags I prefer enum. Before reaching to a conclusion I've one question about the number 'n' of flags and how much value 'n' can grow ?. Only my worry is, once we set the protocol to enum type, as we all know couldn't get another chance to change it later as 'n' increases.


- Rakesh


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/17895/#review41130
-----------------------------------------------------------


On April 24, 2014, 7:43 a.m., Sijie Guo wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/17895/
> -----------------------------------------------------------
> 
> (Updated April 24, 2014, 7:43 a.m.)
> 
> 
> Review request for bookkeeper and Ivan Kelly.
> 
> 
> Bugs: BOOKKEEPER-582
>     https://issues.apache.org/jira/browse/BOOKKEEPER-582
> 
> 
> Repository: bookkeeper-git
> 
> 
> Description
> -------
> 
> - introducing protobuf support for bookkeeper
> - for server: introduce packet processor / EnDecoder for different protocol supports
> - for client: change PCBC to use protobuf to send requests
> - misc changes for protobuf support
> 
> (bookie server is able for backward compatibility) 
> 
> 
> Diffs
> -----
> 
>   bookkeeper-server/pom.xml ebc1198 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/bookie/IndexInMemPageMgr.java 56487aa 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/LedgerChecker.java 28e23d6 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/PendingReadOp.java fb36b90 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/processor/RequestProcessor.java 241f369 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieProtoEncoding.java 1154047 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestHandler.java b922a82 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestProcessor.java 8155b22 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookkeeperProtocol.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBase.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBaseV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PerChannelBookieClient.java a10f7d5 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/proto/BookkeeperProtocol.proto PRE-CREATION 
>   bookkeeper-server/src/main/resources/findbugsExclude.xml 97a6156 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/proto/TestProtoVersions.java 5fcc445 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/replication/AuditorPeriodicCheckTest.java 3f8496f 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/BookieClientTest.java bc05229 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/TestBackwardCompat.java 8376b46 
>   compat-deps/bookkeeper-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/hedwig-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/pom.xml f79582d 
>   hedwig-server/pom.xml 06cf01c 
>   hedwig-server/src/test/java/org/apache/hedwig/server/TestBackwardCompat.java 8da109e 
> 
> Diff: https://reviews.apache.org/r/17895/diff/
> 
> 
> Testing
> -------
> 
> unit tests. backward tests.
> 
> 
> Thanks,
> 
> Sijie Guo
> 
>

Re: Review Request 17895: BOOKKEEPER-582: protobuf support for bookkeeper

Posted by Sijie Guo <gu...@gmail.com>.


> On April 23, 2014, 10:22 a.m., Ivan Kelly wrote:
> > bookkeeper-server/src/main/proto/BookkeeperProtocol.proto, line 33
> > <https://reviews.apache.org/r/17895/diff/2/?file=563033#file563033line33>
> >
> >     This should certainly not be an enum. Otherwise we need to bump the protocol version each time we add an error code.
> >     
> >     Imagine the scenario where both server and client are running 4.3.0. Then the server is upgraded with 4.3.1 which a new error EPRINTERONFIRE. It sends this to the client who throws a decode error.
> 
> Sijie Guo wrote:
>     how could being not enum help this? if it is integer, client still has no idea how to interpret, so it is still invalid response from 4.3.0 client. I thought we reached an agreement on enum on the ticket, no?
> 
> Ivan Kelly wrote:
>     So for version and operationtype, enum is ok. These originate at the client, so if the servers are always upgraded at the client, there's no interoperability issues. Status codes originate at the server though, so it is possible for the server to send a statuscode that is unrecognised to a client. The normal way to handle this would be a "else" or "default:" to pass this up to the client as a BKException.UnexpectedConditionException. If it's an enum, this will throw a decode exception in the netty decoder, which is harder to handle.
>     
>     To resolve this on the server side, by checking the version and only sending errors valid for that version, implies two things. Firstly, every error code change will require the version to be bumped and secondly, that there will need to be a list maintained for which errors are valid for each version. This goes against the motivation for using protobuf in the first place.
> 
> Sijie Guo wrote:
>     this is the application level agreement, no? it doesn't matter that u are using a protobuf protocol or using current protocol, or it also doesn't matter that u are using an integer or an enum. in any case, the best way is as you described, you shouldn't send new status code back to an old client, as the new status code is meaningless to the old client.
> 
> Ivan Kelly wrote:
>     but how do you know its an old client? Only by bumping the version number each time you add an error code. In which case you end up with a whole lot of junk like "if (client.version == X) { send A } else if (client.version == Y) { send B } else if (client.version ..." which is exactly what protobuf was designed to avoid (see "A bit of history" on https://developers.google.com/protocol-buffers/docs/overview).
> 
> Sijie Guo wrote:
>     a else or default branch would make the behavior unpredictable as an old client is treating a new status code as some kind of unknown. as you said, you want to treat them as UnexpectedConditionException. But what does UnexpectedConditionException means? doesn't it mean the sever already breaks backward compatibility, since server couldn't satisfy the old client's request.
>     
>     so still, if server wants to be backward compatibility to clients, in any cases, it needs to know what version of protocol that the client is speaking and handle them accordingly, not just let client to do their job in an unexpected way.
>     
>     I don't see any elegant solutions without detecting protocol version. if you have, please describe how not being enum would avoid this.
> 
> Ivan Kelly wrote:
>     the default behaviour for an unknown error code is something we already use today.
>     https://github.com/apache/bookkeeper/blob/trunk/bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PerChannelBookieClient.java#L714
>     
>     The client only needs to know that the request failed. the point of the different error codes is so that the client could take specific recovery steps. the default behaviour is just to pass the error up.
> 
> Sijie Guo wrote:
>     the default behavior was there just for all already known status codes. but it doesn't mean it is correct for any unknown status codes. and when u are saying 'the client only needs to know that the request failed', you are making an assumption that there is only one status code indicating OK, other status code should be taken as failed. but it isn't true. say in an old protocol, we supported range reads, it responded with OK, list of entry response (0 = <data>, 1 = missing, 2 = missing, 3 = <data>). if we are going to improve our protocol to make communication more efficient, we are going to change the protocol to get rid of transferring missing entries: responding with PARTIAL_OK, list of existing entries (0 = <data>, 3 = <data>). 
>     
>     in this case, if server doesn't distinguish the client's protocol, just respond every range reads with PARTIAL_OK, would did break the compatibility with old protocol, as old protocol treats it as failure by default behavior. in order to maintain backward compatibility, server needs to detect the client's protocol and responds accordingly. as what I said, for backward compatibility, a protocol doesn't really help if it involves behavior in application agreement. and a default behavior is not exact right.
>     
>     for me, using protocol. it means that it is easy for us to add new requests type, add new fields in existing requests. besides that, we need to keep the backward compatibility in our level.
> 
> Ivan Kelly wrote:
>     when i say that 'the client only needs to know that the request failed', it means that the client only needs to recognise the statuses which indicate success. for any request, the status codes which indicate success should never change. For a read request or add request, only OK is SUCCESS. For range read,  only PARTIAL_OK and OK are success. But the client will never send a range read request unless it already knows about PARTIAL_OK.
> 
> Sijie Guo wrote:
>     > “But the client will never send a range read request unless it already knows about PARTIAL_OK.” 
>     
>     the example that I made is that the range read introduced with OK, but if it is going to evolved to have PARTIAL_OK. then that will be an problem.
> 
> Ivan Kelly wrote:
>     Partial_ok doesn't make sense if you're using the concept of packet status and operation status (as mentioned below).
> 
> Sijie Guo wrote:
>     well, if u are talking about a specific case (e.g. range read), I might agree with u. but if you read my comments, it is just the case that I explained how the protocol might be evolved. And my point is and always will be for backward compatibility, the server shouldn't send any unknown codes/fields back to clients that speaks old protocol, this is part of application-level agreement, no matter using enum or integer.
> 
> Rakesh R wrote:
>     Using enum is more readable and would be good for newcomers too. Assume a case where we are introducing new EC for an existing request type at the side server side, EC#NEW_ERR_CODE in 4.3.1 and client is old one 4.3.0. Ideally in this case, bk client should say its unknown code.
>     
>     Does this create any parsing issues at the protobuf ?. If not, I'm OK using enum for the StatusCode too.
> 
> Sijie Guo wrote:
>     if you read the conversation about this, my point is that for correct backward compatibility, we should avoid sending unknown error codes back to an old client.
> 
> Rakesh R wrote:
>     So server should have version specific checks and generates the error codes, isn't it ?.
> 
> Sijie Guo wrote:
>     yes. exact as what I pointed. sending responses matching exact version of protocol, isn't that exactly for application level backward compatible? why this would be the concern?
> 
> Rakesh R wrote:
>     There is no big concern here. I'm trying to understand the current approach and the future path to avoid any compatibility issues later.

for backward compatibility, it is comprised of wire compatibility and application-semantic compatibility. using protobuf, we could easily achieve wire compatibility by adding new optional fields. for application-semantic, the server needs to detect what version of the client is talking, and send correct version of responses according to its version. the version field in the request/response structure helps achieving this.


- Sijie


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/17895/#review41130
-----------------------------------------------------------


On April 24, 2014, 7:43 a.m., Sijie Guo wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/17895/
> -----------------------------------------------------------
> 
> (Updated April 24, 2014, 7:43 a.m.)
> 
> 
> Review request for bookkeeper and Ivan Kelly.
> 
> 
> Bugs: BOOKKEEPER-582
>     https://issues.apache.org/jira/browse/BOOKKEEPER-582
> 
> 
> Repository: bookkeeper-git
> 
> 
> Description
> -------
> 
> - introducing protobuf support for bookkeeper
> - for server: introduce packet processor / EnDecoder for different protocol supports
> - for client: change PCBC to use protobuf to send requests
> - misc changes for protobuf support
> 
> (bookie server is able for backward compatibility) 
> 
> 
> Diffs
> -----
> 
>   bookkeeper-server/pom.xml ebc1198 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/bookie/IndexInMemPageMgr.java 56487aa 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/LedgerChecker.java 28e23d6 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/PendingReadOp.java fb36b90 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/processor/RequestProcessor.java 241f369 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieProtoEncoding.java 1154047 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestHandler.java b922a82 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestProcessor.java 8155b22 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookkeeperProtocol.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBase.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBaseV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PerChannelBookieClient.java a10f7d5 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/proto/BookkeeperProtocol.proto PRE-CREATION 
>   bookkeeper-server/src/main/resources/findbugsExclude.xml 97a6156 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/proto/TestProtoVersions.java 5fcc445 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/replication/AuditorPeriodicCheckTest.java 3f8496f 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/BookieClientTest.java bc05229 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/TestBackwardCompat.java 8376b46 
>   compat-deps/bookkeeper-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/hedwig-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/pom.xml f79582d 
>   hedwig-server/pom.xml 06cf01c 
>   hedwig-server/src/test/java/org/apache/hedwig/server/TestBackwardCompat.java 8da109e 
> 
> Diff: https://reviews.apache.org/r/17895/diff/
> 
> 
> Testing
> -------
> 
> unit tests. backward tests.
> 
> 
> Thanks,
> 
> Sijie Guo
> 
>

Re: Review Request 17895: BOOKKEEPER-582: protobuf support for bookkeeper

Posted by Rakesh R <ra...@huawei.com>.


> On April 23, 2014, 10:22 a.m., Ivan Kelly wrote:
> > bookkeeper-server/src/main/proto/BookkeeperProtocol.proto, line 33
> > <https://reviews.apache.org/r/17895/diff/2/?file=563033#file563033line33>
> >
> >     This should certainly not be an enum. Otherwise we need to bump the protocol version each time we add an error code.
> >     
> >     Imagine the scenario where both server and client are running 4.3.0. Then the server is upgraded with 4.3.1 which a new error EPRINTERONFIRE. It sends this to the client who throws a decode error.
> 
> Sijie Guo wrote:
>     how could being not enum help this? if it is integer, client still has no idea how to interpret, so it is still invalid response from 4.3.0 client. I thought we reached an agreement on enum on the ticket, no?
> 
> Ivan Kelly wrote:
>     So for version and operationtype, enum is ok. These originate at the client, so if the servers are always upgraded at the client, there's no interoperability issues. Status codes originate at the server though, so it is possible for the server to send a statuscode that is unrecognised to a client. The normal way to handle this would be a "else" or "default:" to pass this up to the client as a BKException.UnexpectedConditionException. If it's an enum, this will throw a decode exception in the netty decoder, which is harder to handle.
>     
>     To resolve this on the server side, by checking the version and only sending errors valid for that version, implies two things. Firstly, every error code change will require the version to be bumped and secondly, that there will need to be a list maintained for which errors are valid for each version. This goes against the motivation for using protobuf in the first place.
> 
> Sijie Guo wrote:
>     this is the application level agreement, no? it doesn't matter that u are using a protobuf protocol or using current protocol, or it also doesn't matter that u are using an integer or an enum. in any case, the best way is as you described, you shouldn't send new status code back to an old client, as the new status code is meaningless to the old client.
> 
> Ivan Kelly wrote:
>     but how do you know its an old client? Only by bumping the version number each time you add an error code. In which case you end up with a whole lot of junk like "if (client.version == X) { send A } else if (client.version == Y) { send B } else if (client.version ..." which is exactly what protobuf was designed to avoid (see "A bit of history" on https://developers.google.com/protocol-buffers/docs/overview).
> 
> Sijie Guo wrote:
>     a else or default branch would make the behavior unpredictable as an old client is treating a new status code as some kind of unknown. as you said, you want to treat them as UnexpectedConditionException. But what does UnexpectedConditionException means? doesn't it mean the sever already breaks backward compatibility, since server couldn't satisfy the old client's request.
>     
>     so still, if server wants to be backward compatibility to clients, in any cases, it needs to know what version of protocol that the client is speaking and handle them accordingly, not just let client to do their job in an unexpected way.
>     
>     I don't see any elegant solutions without detecting protocol version. if you have, please describe how not being enum would avoid this.
> 
> Ivan Kelly wrote:
>     the default behaviour for an unknown error code is something we already use today.
>     https://github.com/apache/bookkeeper/blob/trunk/bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PerChannelBookieClient.java#L714
>     
>     The client only needs to know that the request failed. the point of the different error codes is so that the client could take specific recovery steps. the default behaviour is just to pass the error up.
> 
> Sijie Guo wrote:
>     the default behavior was there just for all already known status codes. but it doesn't mean it is correct for any unknown status codes. and when u are saying 'the client only needs to know that the request failed', you are making an assumption that there is only one status code indicating OK, other status code should be taken as failed. but it isn't true. say in an old protocol, we supported range reads, it responded with OK, list of entry response (0 = <data>, 1 = missing, 2 = missing, 3 = <data>). if we are going to improve our protocol to make communication more efficient, we are going to change the protocol to get rid of transferring missing entries: responding with PARTIAL_OK, list of existing entries (0 = <data>, 3 = <data>). 
>     
>     in this case, if server doesn't distinguish the client's protocol, just respond every range reads with PARTIAL_OK, would did break the compatibility with old protocol, as old protocol treats it as failure by default behavior. in order to maintain backward compatibility, server needs to detect the client's protocol and responds accordingly. as what I said, for backward compatibility, a protocol doesn't really help if it involves behavior in application agreement. and a default behavior is not exact right.
>     
>     for me, using protocol. it means that it is easy for us to add new requests type, add new fields in existing requests. besides that, we need to keep the backward compatibility in our level.
> 
> Ivan Kelly wrote:
>     when i say that 'the client only needs to know that the request failed', it means that the client only needs to recognise the statuses which indicate success. for any request, the status codes which indicate success should never change. For a read request or add request, only OK is SUCCESS. For range read,  only PARTIAL_OK and OK are success. But the client will never send a range read request unless it already knows about PARTIAL_OK.
> 
> Sijie Guo wrote:
>     > “But the client will never send a range read request unless it already knows about PARTIAL_OK.” 
>     
>     the example that I made is that the range read introduced with OK, but if it is going to evolved to have PARTIAL_OK. then that will be an problem.
> 
> Ivan Kelly wrote:
>     Partial_ok doesn't make sense if you're using the concept of packet status and operation status (as mentioned below).
> 
> Sijie Guo wrote:
>     well, if u are talking about a specific case (e.g. range read), I might agree with u. but if you read my comments, it is just the case that I explained how the protocol might be evolved. And my point is and always will be for backward compatibility, the server shouldn't send any unknown codes/fields back to clients that speaks old protocol, this is part of application-level agreement, no matter using enum or integer.
> 
> Rakesh R wrote:
>     Using enum is more readable and would be good for newcomers too. Assume a case where we are introducing new EC for an existing request type at the side server side, EC#NEW_ERR_CODE in 4.3.1 and client is old one 4.3.0. Ideally in this case, bk client should say its unknown code.
>     
>     Does this create any parsing issues at the protobuf ?. If not, I'm OK using enum for the StatusCode too.
> 
> Sijie Guo wrote:
>     if you read the conversation about this, my point is that for correct backward compatibility, we should avoid sending unknown error codes back to an old client.
> 
> Rakesh R wrote:
>     So server should have version specific checks and generates the error codes, isn't it ?.
> 
> Sijie Guo wrote:
>     yes. exact as what I pointed. sending responses matching exact version of protocol, isn't that exactly for application level backward compatible? why this would be the concern?

There is no big concern here. I'm trying to understand the current approach and the future path to avoid any compatibility issues later.


- Rakesh


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/17895/#review41130
-----------------------------------------------------------


On April 24, 2014, 7:43 a.m., Sijie Guo wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/17895/
> -----------------------------------------------------------
> 
> (Updated April 24, 2014, 7:43 a.m.)
> 
> 
> Review request for bookkeeper and Ivan Kelly.
> 
> 
> Bugs: BOOKKEEPER-582
>     https://issues.apache.org/jira/browse/BOOKKEEPER-582
> 
> 
> Repository: bookkeeper-git
> 
> 
> Description
> -------
> 
> - introducing protobuf support for bookkeeper
> - for server: introduce packet processor / EnDecoder for different protocol supports
> - for client: change PCBC to use protobuf to send requests
> - misc changes for protobuf support
> 
> (bookie server is able for backward compatibility) 
> 
> 
> Diffs
> -----
> 
>   bookkeeper-server/pom.xml ebc1198 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/bookie/IndexInMemPageMgr.java 56487aa 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/LedgerChecker.java 28e23d6 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/PendingReadOp.java fb36b90 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/processor/RequestProcessor.java 241f369 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieProtoEncoding.java 1154047 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestHandler.java b922a82 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestProcessor.java 8155b22 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookkeeperProtocol.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBase.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBaseV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PerChannelBookieClient.java a10f7d5 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/proto/BookkeeperProtocol.proto PRE-CREATION 
>   bookkeeper-server/src/main/resources/findbugsExclude.xml 97a6156 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/proto/TestProtoVersions.java 5fcc445 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/replication/AuditorPeriodicCheckTest.java 3f8496f 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/BookieClientTest.java bc05229 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/TestBackwardCompat.java 8376b46 
>   compat-deps/bookkeeper-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/hedwig-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/pom.xml f79582d 
>   hedwig-server/pom.xml 06cf01c 
>   hedwig-server/src/test/java/org/apache/hedwig/server/TestBackwardCompat.java 8da109e 
> 
> Diff: https://reviews.apache.org/r/17895/diff/
> 
> 
> Testing
> -------
> 
> unit tests. backward tests.
> 
> 
> Thanks,
> 
> Sijie Guo
> 
>

Re: Review Request 17895: BOOKKEEPER-582: protobuf support for bookkeeper

Posted by Ivan Kelly <iv...@apache.org>.


> On April 23, 2014, 10:22 a.m., Ivan Kelly wrote:
> > bookkeeper-server/src/main/proto/BookkeeperProtocol.proto, line 33
> > <https://reviews.apache.org/r/17895/diff/2/?file=563033#file563033line33>
> >
> >     This should certainly not be an enum. Otherwise we need to bump the protocol version each time we add an error code.
> >     
> >     Imagine the scenario where both server and client are running 4.3.0. Then the server is upgraded with 4.3.1 which a new error EPRINTERONFIRE. It sends this to the client who throws a decode error.
> 
> Sijie Guo wrote:
>     how could being not enum help this? if it is integer, client still has no idea how to interpret, so it is still invalid response from 4.3.0 client. I thought we reached an agreement on enum on the ticket, no?
> 
> Ivan Kelly wrote:
>     So for version and operationtype, enum is ok. These originate at the client, so if the servers are always upgraded at the client, there's no interoperability issues. Status codes originate at the server though, so it is possible for the server to send a statuscode that is unrecognised to a client. The normal way to handle this would be a "else" or "default:" to pass this up to the client as a BKException.UnexpectedConditionException. If it's an enum, this will throw a decode exception in the netty decoder, which is harder to handle.
>     
>     To resolve this on the server side, by checking the version and only sending errors valid for that version, implies two things. Firstly, every error code change will require the version to be bumped and secondly, that there will need to be a list maintained for which errors are valid for each version. This goes against the motivation for using protobuf in the first place.
> 
> Sijie Guo wrote:
>     this is the application level agreement, no? it doesn't matter that u are using a protobuf protocol or using current protocol, or it also doesn't matter that u are using an integer or an enum. in any case, the best way is as you described, you shouldn't send new status code back to an old client, as the new status code is meaningless to the old client.

but how do you know its an old client? Only by bumping the version number each time you add an error code. In which case you end up with a whole lot of junk like "if (client.version == X) { send A } else if (client.version == Y) { send B } else if (client.version ..." which is exactly what protobuf was designed to avoid (see "A bit of history" on https://developers.google.com/protocol-buffers/docs/overview).


> On April 23, 2014, 10:22 a.m., Ivan Kelly wrote:
> > bookkeeper-server/src/main/proto/BookkeeperProtocol.proto, line 65
> > <https://reviews.apache.org/r/17895/diff/2/?file=563033#file563033line65>
> >
> >     Comment 1.
> >     OperationType is redundant. The server can do #hasReadRequest and #hasAddRequest to check the request to check the type. We shouldn't send redundant data over the wire where possible.
> >     
> >     Comment 2.
> >     it better to make the absolute minimum to be required. Required is forever, and these may not be.
> >     
> >     https://developers.google.com/protocol-buffers/docs/proto
> >
> 
> Sijie Guo wrote:
>     > comment 1.
>     
>     OperationType will make request more clear and specify and less if...else branches. And OperationType is used for PCBC to unify all requests handling. so we don't need to have individual maps to maintain requests each time we added a new type of requests.
>     
>     > comment 2.
>     
>     if reply to comment 1 works for u, I don't see any reason why operation would not be a required.
> 
> Ivan Kelly wrote:
>     Ok. I can live with it, though I still think it's a little cumbersome. Regarding requiredness, I still think it should be optional. All fields should be optional by default to give you as much freedom to evolve the protocol in the future as possible. Especially something, which is not 100% essential to the protocol, like this field.
> 
> Sijie Guo wrote:
>     for those fields that already exist in the origin protocol, I don't see we are going to remove them. that's why we put it as required.

We shouldnt prelude the possibility though. What problem could making them optional cause? 


> On April 23, 2014, 10:22 a.m., Ivan Kelly wrote:
> > bookkeeper-server/src/main/proto/BookkeeperProtocol.proto, line 80
> > <https://reviews.apache.org/r/17895/diff/2/?file=563033#file563033line80>
> >
> >     This would be better served with a boolean. protobuf will keep it compact.
> 
> Sijie Guo wrote:
>     being Flag will make it easier to add other flags in future.
> 
> Ivan Kelly wrote:
>     No it doesn't. Lets say you do add another flag in the future. How do you specify that it's both a FENCE_LEDGER and NEW_FLAG? You need the field to be repeated, and then you need code to loop through the flags. Compared to msg.isFenceLedger(), this seems much more cumbersome.
> 
> Sijie Guo wrote:
>     I don't say this field is bits-set-like of flags. as the long poll changes we mentioned, we are going to add a new flag 'ENTRY_PIGGYBACK' for read. so a read request is either a normal read (without Flag), a fence read (flag = FENCE_LEDGER) or a piggyback read (flag = ENTRY_PIGGYBACK). Being repeated will be kind of complicated, as you need to loop all possible permutation.

This is ugly and shortsighted. There may well be a case in the future where two flags need to be specified. What do we do then? Add a flags2 field? 


> On April 23, 2014, 10:22 a.m., Ivan Kelly wrote:
> > bookkeeper-server/src/main/proto/BookkeeperProtocol.proto, line 104
> > <https://reviews.apache.org/r/17895/diff/2/?file=563033#file563033line104>
> >
> >     You're sending StatusCode twice, every time. Firstly, shouldn't be an enum as stated above. Secondly, shouldn't be required.
> 
> Sijie Guo wrote:
>     > enum
>     
>     as the comments above.
>     
>     > status code twice.
>     
>     the status code for ReadResponse/AddResponse is for individual responses. if we are going to support kind of batch reads, the status code of Response means either the whole batch succeed or not while the individual read responses might have different status codes (e.g OK or NotExists). That is why it exists two places.
>     
>     > required
>     
>     as the comments above
> 
> Ivan Kelly wrote:
>     Per request makes sense. However, in that case, can't you just remove the per packet status?
> 
> Sijie Guo wrote:
>     Nope. the packet status indicates whether the packet succeed or not. say if it is batch read, if the total batch read failed, it would set the whole packet status to be failed and there would be no individual responses in the packet since the whole batch failed.

Then it should have a different name. Like entryStatus & packetStatus. But then you also have a consistency problem. What is packetStatus is OK, but one entryStatus is an error? Will there be a SOME_OK error? In what scenario would a whole read batch fail?


- Ivan


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/17895/#review41130
-----------------------------------------------------------


On April 24, 2014, 7:43 a.m., Sijie Guo wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/17895/
> -----------------------------------------------------------
> 
> (Updated April 24, 2014, 7:43 a.m.)
> 
> 
> Review request for bookkeeper and Ivan Kelly.
> 
> 
> Bugs: BOOKKEEPER-582
>     https://issues.apache.org/jira/browse/BOOKKEEPER-582
> 
> 
> Repository: bookkeeper-git
> 
> 
> Description
> -------
> 
> - introducing protobuf support for bookkeeper
> - for server: introduce packet processor / EnDecoder for different protocol supports
> - for client: change PCBC to use protobuf to send requests
> - misc changes for protobuf support
> 
> (bookie server is able for backward compatibility) 
> 
> 
> Diffs
> -----
> 
>   bookkeeper-server/pom.xml ebc1198 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/bookie/IndexInMemPageMgr.java 56487aa 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/LedgerChecker.java 28e23d6 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/PendingReadOp.java fb36b90 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/processor/RequestProcessor.java 241f369 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieProtoEncoding.java 1154047 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestHandler.java b922a82 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestProcessor.java 8155b22 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookkeeperProtocol.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBase.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBaseV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PerChannelBookieClient.java a10f7d5 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/proto/BookkeeperProtocol.proto PRE-CREATION 
>   bookkeeper-server/src/main/resources/findbugsExclude.xml 97a6156 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/proto/TestProtoVersions.java 5fcc445 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/replication/AuditorPeriodicCheckTest.java 3f8496f 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/BookieClientTest.java bc05229 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/TestBackwardCompat.java 8376b46 
>   compat-deps/bookkeeper-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/hedwig-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/pom.xml f79582d 
>   hedwig-server/pom.xml 06cf01c 
>   hedwig-server/src/test/java/org/apache/hedwig/server/TestBackwardCompat.java 8da109e 
> 
> Diff: https://reviews.apache.org/r/17895/diff/
> 
> 
> Testing
> -------
> 
> unit tests. backward tests.
> 
> 
> Thanks,
> 
> Sijie Guo
> 
>

Re: Review Request 17895: BOOKKEEPER-582: protobuf support for bookkeeper

Posted by Rakesh R <ra...@huawei.com>.


> On April 23, 2014, 10:22 a.m., Ivan Kelly wrote:
> > bookkeeper-server/src/main/proto/BookkeeperProtocol.proto, line 33
> > <https://reviews.apache.org/r/17895/diff/2/?file=563033#file563033line33>
> >
> >     This should certainly not be an enum. Otherwise we need to bump the protocol version each time we add an error code.
> >     
> >     Imagine the scenario where both server and client are running 4.3.0. Then the server is upgraded with 4.3.1 which a new error EPRINTERONFIRE. It sends this to the client who throws a decode error.
> 
> Sijie Guo wrote:
>     how could being not enum help this? if it is integer, client still has no idea how to interpret, so it is still invalid response from 4.3.0 client. I thought we reached an agreement on enum on the ticket, no?
> 
> Ivan Kelly wrote:
>     So for version and operationtype, enum is ok. These originate at the client, so if the servers are always upgraded at the client, there's no interoperability issues. Status codes originate at the server though, so it is possible for the server to send a statuscode that is unrecognised to a client. The normal way to handle this would be a "else" or "default:" to pass this up to the client as a BKException.UnexpectedConditionException. If it's an enum, this will throw a decode exception in the netty decoder, which is harder to handle.
>     
>     To resolve this on the server side, by checking the version and only sending errors valid for that version, implies two things. Firstly, every error code change will require the version to be bumped and secondly, that there will need to be a list maintained for which errors are valid for each version. This goes against the motivation for using protobuf in the first place.
> 
> Sijie Guo wrote:
>     this is the application level agreement, no? it doesn't matter that u are using a protobuf protocol or using current protocol, or it also doesn't matter that u are using an integer or an enum. in any case, the best way is as you described, you shouldn't send new status code back to an old client, as the new status code is meaningless to the old client.
> 
> Ivan Kelly wrote:
>     but how do you know its an old client? Only by bumping the version number each time you add an error code. In which case you end up with a whole lot of junk like "if (client.version == X) { send A } else if (client.version == Y) { send B } else if (client.version ..." which is exactly what protobuf was designed to avoid (see "A bit of history" on https://developers.google.com/protocol-buffers/docs/overview).
> 
> Sijie Guo wrote:
>     a else or default branch would make the behavior unpredictable as an old client is treating a new status code as some kind of unknown. as you said, you want to treat them as UnexpectedConditionException. But what does UnexpectedConditionException means? doesn't it mean the sever already breaks backward compatibility, since server couldn't satisfy the old client's request.
>     
>     so still, if server wants to be backward compatibility to clients, in any cases, it needs to know what version of protocol that the client is speaking and handle them accordingly, not just let client to do their job in an unexpected way.
>     
>     I don't see any elegant solutions without detecting protocol version. if you have, please describe how not being enum would avoid this.
> 
> Ivan Kelly wrote:
>     the default behaviour for an unknown error code is something we already use today.
>     https://github.com/apache/bookkeeper/blob/trunk/bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PerChannelBookieClient.java#L714
>     
>     The client only needs to know that the request failed. the point of the different error codes is so that the client could take specific recovery steps. the default behaviour is just to pass the error up.
> 
> Sijie Guo wrote:
>     the default behavior was there just for all already known status codes. but it doesn't mean it is correct for any unknown status codes. and when u are saying 'the client only needs to know that the request failed', you are making an assumption that there is only one status code indicating OK, other status code should be taken as failed. but it isn't true. say in an old protocol, we supported range reads, it responded with OK, list of entry response (0 = <data>, 1 = missing, 2 = missing, 3 = <data>). if we are going to improve our protocol to make communication more efficient, we are going to change the protocol to get rid of transferring missing entries: responding with PARTIAL_OK, list of existing entries (0 = <data>, 3 = <data>). 
>     
>     in this case, if server doesn't distinguish the client's protocol, just respond every range reads with PARTIAL_OK, would did break the compatibility with old protocol, as old protocol treats it as failure by default behavior. in order to maintain backward compatibility, server needs to detect the client's protocol and responds accordingly. as what I said, for backward compatibility, a protocol doesn't really help if it involves behavior in application agreement. and a default behavior is not exact right.
>     
>     for me, using protocol. it means that it is easy for us to add new requests type, add new fields in existing requests. besides that, we need to keep the backward compatibility in our level.
> 
> Ivan Kelly wrote:
>     when i say that 'the client only needs to know that the request failed', it means that the client only needs to recognise the statuses which indicate success. for any request, the status codes which indicate success should never change. For a read request or add request, only OK is SUCCESS. For range read,  only PARTIAL_OK and OK are success. But the client will never send a range read request unless it already knows about PARTIAL_OK.
> 
> Sijie Guo wrote:
>     > “But the client will never send a range read request unless it already knows about PARTIAL_OK.” 
>     
>     the example that I made is that the range read introduced with OK, but if it is going to evolved to have PARTIAL_OK. then that will be an problem.
> 
> Ivan Kelly wrote:
>     Partial_ok doesn't make sense if you're using the concept of packet status and operation status (as mentioned below).
> 
> Sijie Guo wrote:
>     well, if u are talking about a specific case (e.g. range read), I might agree with u. but if you read my comments, it is just the case that I explained how the protocol might be evolved. And my point is and always will be for backward compatibility, the server shouldn't send any unknown codes/fields back to clients that speaks old protocol, this is part of application-level agreement, no matter using enum or integer.
> 
> Rakesh R wrote:
>     Using enum is more readable and would be good for newcomers too. Assume a case where we are introducing new EC for an existing request type at the side server side, EC#NEW_ERR_CODE in 4.3.1 and client is old one 4.3.0. Ideally in this case, bk client should say its unknown code.
>     
>     Does this create any parsing issues at the protobuf ?. If not, I'm OK using enum for the StatusCode too.
> 
> Sijie Guo wrote:
>     if you read the conversation about this, my point is that for correct backward compatibility, we should avoid sending unknown error codes back to an old client.
> 
> Rakesh R wrote:
>     So server should have version specific checks and generates the error codes, isn't it ?.
> 
> Sijie Guo wrote:
>     yes. exact as what I pointed. sending responses matching exact version of protocol, isn't that exactly for application level backward compatible? why this would be the concern?
> 
> Rakesh R wrote:
>     There is no big concern here. I'm trying to understand the current approach and the future path to avoid any compatibility issues later.
> 
> Sijie Guo wrote:
>     for backward compatibility, it is comprised of wire compatibility and application-semantic compatibility. using protobuf, we could easily achieve wire compatibility by adding new optional fields. for application-semantic, the server needs to detect what version of the client is talking, and send correct version of responses according to its version. the version field in the request/response structure helps achieving this.
> 
> Rakesh R wrote:
>     Maintaining version list has its own complexities, but again it depends on the client side requirements. As I know protobuf parser would not get decode exceptions if any unknown enum code comes from server, instead this will return a null value. If this is the behavior of protobuf, then today its not a blocker for this patch. Because in your patch, you have already handled unknown error code in PerChannelBookieClient#statusCodeToExceptionCode() and treats this code as an op failure.
> 
> Sijie Guo wrote:
>     version list is more for application level semantic backward compatibility. a clear specific version for backward compatibility would be more clear than any implicit solution. although it might introduce code, it is clear for maintenance.

OK. My point is, since we have already unknown error code handling at the client side, we can discuss this case alone later. Today its not a concern for this patch, but we can atleast remember this point for future discussion :-)

+        Integer rcToRet = statusCodeToExceptionCode(status);
+        if (null == rcToRet) {
+            rcToRet = BKException.Code.WriteException;

+        Integer rcToRet = statusCodeToExceptionCode(status);
+        if (null == rcToRet) {
+            rcToRet = BKException.Code.ReadException;


- Rakesh


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/17895/#review41130
-----------------------------------------------------------


On April 24, 2014, 7:43 a.m., Sijie Guo wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/17895/
> -----------------------------------------------------------
> 
> (Updated April 24, 2014, 7:43 a.m.)
> 
> 
> Review request for bookkeeper and Ivan Kelly.
> 
> 
> Bugs: BOOKKEEPER-582
>     https://issues.apache.org/jira/browse/BOOKKEEPER-582
> 
> 
> Repository: bookkeeper-git
> 
> 
> Description
> -------
> 
> - introducing protobuf support for bookkeeper
> - for server: introduce packet processor / EnDecoder for different protocol supports
> - for client: change PCBC to use protobuf to send requests
> - misc changes for protobuf support
> 
> (bookie server is able for backward compatibility) 
> 
> 
> Diffs
> -----
> 
>   bookkeeper-server/pom.xml ebc1198 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/bookie/IndexInMemPageMgr.java 56487aa 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/LedgerChecker.java 28e23d6 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/PendingReadOp.java fb36b90 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/processor/RequestProcessor.java 241f369 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieProtoEncoding.java 1154047 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestHandler.java b922a82 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestProcessor.java 8155b22 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookkeeperProtocol.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBase.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBaseV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PerChannelBookieClient.java a10f7d5 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/proto/BookkeeperProtocol.proto PRE-CREATION 
>   bookkeeper-server/src/main/resources/findbugsExclude.xml 97a6156 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/proto/TestProtoVersions.java 5fcc445 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/replication/AuditorPeriodicCheckTest.java 3f8496f 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/BookieClientTest.java bc05229 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/TestBackwardCompat.java 8376b46 
>   compat-deps/bookkeeper-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/hedwig-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/pom.xml f79582d 
>   hedwig-server/pom.xml 06cf01c 
>   hedwig-server/src/test/java/org/apache/hedwig/server/TestBackwardCompat.java 8da109e 
> 
> Diff: https://reviews.apache.org/r/17895/diff/
> 
> 
> Testing
> -------
> 
> unit tests. backward tests.
> 
> 
> Thanks,
> 
> Sijie Guo
> 
>

Re: Review Request 17895: BOOKKEEPER-582: protobuf support for bookkeeper

Posted by Sijie Guo <gu...@gmail.com>.


> On April 23, 2014, 10:22 a.m., Ivan Kelly wrote:
> > bookkeeper-server/src/main/proto/BookkeeperProtocol.proto, line 65
> > <https://reviews.apache.org/r/17895/diff/2/?file=563033#file563033line65>
> >
> >     Comment 1.
> >     OperationType is redundant. The server can do #hasReadRequest and #hasAddRequest to check the request to check the type. We shouldn't send redundant data over the wire where possible.
> >     
> >     Comment 2.
> >     it better to make the absolute minimum to be required. Required is forever, and these may not be.
> >     
> >     https://developers.google.com/protocol-buffers/docs/proto
> >
> 
> Sijie Guo wrote:
>     > comment 1.
>     
>     OperationType will make request more clear and specify and less if...else branches. And OperationType is used for PCBC to unify all requests handling. so we don't need to have individual maps to maintain requests each time we added a new type of requests.
>     
>     > comment 2.
>     
>     if reply to comment 1 works for u, I don't see any reason why operation would not be a required.
> 
> Ivan Kelly wrote:
>     Ok. I can live with it, though I still think it's a little cumbersome. Regarding requiredness, I still think it should be optional. All fields should be optional by default to give you as much freedom to evolve the protocol in the future as possible. Especially something, which is not 100% essential to the protocol, like this field.
> 
> Sijie Guo wrote:
>     for those fields that already exist in the origin protocol, I don't see we are going to remove them. that's why we put it as required.
> 
> Ivan Kelly wrote:
>     We shouldnt prelude the possibility though. What problem could making them optional cause?
> 
> Sijie Guo wrote:
>     what does an response w/o OperationType mean? How PCBC would handle this? as I said, OperationType is somehow guiding us to dispatch the request and response. so it is required.
> 
> Ivan Kelly wrote:
>     the operation type can be inferred from the contents as i said already. So OperationType itself isnt actually required, so we should lock it in at this point.
> 
> Sijie Guo wrote:
>     say you have A, B, C types of requests, you have resp_A, resp_B, resp_C optional fields in response. if using OperationType, you explicitly know what response that the request is for. it reduce the branches that u need to check if the response is valid or not: for example, for response A, it just need to check if resp_A exists or not. if not, it is an invalid response for A. you don't need to touch resp_B and resp_C.
>     
>     if OperationType is not used, you need to write lots of if..else branches to identify what's the response for. e.g. hasResp_A & !hasResp_B & !hasResp_C is for request type A. even worser, if you are adding new request type, you need to change all the if...else branches.
> 
> Ivan Kelly wrote:
>     You dont need to check all negative cases. But thats beside the point. My point is that it is conceivable to not have operationType, even though im ok will it going through with this patch, and since it is conceivable for it to be absent, we should leave open the possibility by making it optional.

sure for positive possibilities, we should leave them there for protocol evaluation. if this possibility will introduce negative effects, why not just avoid it? isn't a OperationType make things clear and robust, and much easier for maintenance?


- Sijie


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/17895/#review41130
-----------------------------------------------------------


On April 24, 2014, 7:43 a.m., Sijie Guo wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/17895/
> -----------------------------------------------------------
> 
> (Updated April 24, 2014, 7:43 a.m.)
> 
> 
> Review request for bookkeeper and Ivan Kelly.
> 
> 
> Bugs: BOOKKEEPER-582
>     https://issues.apache.org/jira/browse/BOOKKEEPER-582
> 
> 
> Repository: bookkeeper-git
> 
> 
> Description
> -------
> 
> - introducing protobuf support for bookkeeper
> - for server: introduce packet processor / EnDecoder for different protocol supports
> - for client: change PCBC to use protobuf to send requests
> - misc changes for protobuf support
> 
> (bookie server is able for backward compatibility) 
> 
> 
> Diffs
> -----
> 
>   bookkeeper-server/pom.xml ebc1198 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/bookie/IndexInMemPageMgr.java 56487aa 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/LedgerChecker.java 28e23d6 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/PendingReadOp.java fb36b90 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/processor/RequestProcessor.java 241f369 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieProtoEncoding.java 1154047 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestHandler.java b922a82 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestProcessor.java 8155b22 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookkeeperProtocol.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBase.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBaseV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PerChannelBookieClient.java a10f7d5 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/proto/BookkeeperProtocol.proto PRE-CREATION 
>   bookkeeper-server/src/main/resources/findbugsExclude.xml 97a6156 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/proto/TestProtoVersions.java 5fcc445 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/replication/AuditorPeriodicCheckTest.java 3f8496f 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/BookieClientTest.java bc05229 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/TestBackwardCompat.java 8376b46 
>   compat-deps/bookkeeper-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/hedwig-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/pom.xml f79582d 
>   hedwig-server/pom.xml 06cf01c 
>   hedwig-server/src/test/java/org/apache/hedwig/server/TestBackwardCompat.java 8da109e 
> 
> Diff: https://reviews.apache.org/r/17895/diff/
> 
> 
> Testing
> -------
> 
> unit tests. backward tests.
> 
> 
> Thanks,
> 
> Sijie Guo
> 
>

Re: Review Request 17895: BOOKKEEPER-582: protobuf support for bookkeeper

Posted by Ivan Kelly <iv...@apache.org>.


> On April 23, 2014, 10:22 a.m., Ivan Kelly wrote:
> > bookkeeper-server/src/main/proto/BookkeeperProtocol.proto, line 104
> > <https://reviews.apache.org/r/17895/diff/2/?file=563033#file563033line104>
> >
> >     You're sending StatusCode twice, every time. Firstly, shouldn't be an enum as stated above. Secondly, shouldn't be required.
> 
> Sijie Guo wrote:
>     > enum
>     
>     as the comments above.
>     
>     > status code twice.
>     
>     the status code for ReadResponse/AddResponse is for individual responses. if we are going to support kind of batch reads, the status code of Response means either the whole batch succeed or not while the individual read responses might have different status codes (e.g OK or NotExists). That is why it exists two places.
>     
>     > required
>     
>     as the comments above
> 
> Ivan Kelly wrote:
>     Per request makes sense. However, in that case, can't you just remove the per packet status?
> 
> Sijie Guo wrote:
>     Nope. the packet status indicates whether the packet succeed or not. say if it is batch read, if the total batch read failed, it would set the whole packet status to be failed and there would be no individual responses in the packet since the whole batch failed.
> 
> Ivan Kelly wrote:
>     Then it should have a different name. Like entryStatus & packetStatus. But then you also have a consistency problem. What is packetStatus is OK, but one entryStatus is an error? Will there be a SOME_OK error? In what scenario would a whole read batch fail?
> 
> Sijie Guo wrote:
>     if ledger isn't exists, then a packet status with NoSuchLedgerExists is returned. if ledger exists, but some entries are missing, so ok is returned for the packet, but NoSuchEntry would be returned for the missing entries.
> 
> Ivan Kelly wrote:
>     this would be better handled with a batch intermediatory message, defined like
>     
>     message Response {
>         required BKPacketHeader header = 1;
>     
>         optional ReadResponse readResponse = 100;
>         optional AddResponse addResponse = 101;
>         optional BatchReadResponse batchReadResponse = 102;
>     }
>     
>     message ReadResponse {
>         required StatusCode status = 1;
>         required int64 ledgerId = 2;
>         required int64 entryId = 3;
>         optional bytes body = 4;
>     }
>     
>     message BatchReadResponse {
>         optional StatusCode status = 1;
>         repeated ReadResponse entries = 2;
>     }
>     
>     message AddResponse {
>         required StatusCode status = 1;
>         required int64 ledgerId = 2;
>         required int64 entryId = 3;
>     }
>
> 
> Sijie Guo wrote:
>     the point of differentiating the status code in packet from the one in operations. there are common status codes which are in packet level not related to individual operations, like 'bad request', 'authentication failure' etc, in this case they could be handled in packet level rather than operations level. otherwise, you need to add duplicated logic to handle those common things in operation responses each time you added new type of requests. doesn't this make a call for separating packet status from operation status?

>  otherwise, you need to add duplicated logic to handle those common things in operation responses each time you added new type of requests.
You have duplicate logic here anyhow. (PerChannelBookieClient.java:633)
It does make some sense to have a packet level status and an op level status. But then they shouldn't share codes. StatusCode should be split into PacketStatusCode and OpStatusCode.


> On April 23, 2014, 10:22 a.m., Ivan Kelly wrote:
> > bookkeeper-server/src/main/proto/BookkeeperProtocol.proto, line 33
> > <https://reviews.apache.org/r/17895/diff/2/?file=563033#file563033line33>
> >
> >     This should certainly not be an enum. Otherwise we need to bump the protocol version each time we add an error code.
> >     
> >     Imagine the scenario where both server and client are running 4.3.0. Then the server is upgraded with 4.3.1 which a new error EPRINTERONFIRE. It sends this to the client who throws a decode error.
> 
> Sijie Guo wrote:
>     how could being not enum help this? if it is integer, client still has no idea how to interpret, so it is still invalid response from 4.3.0 client. I thought we reached an agreement on enum on the ticket, no?
> 
> Ivan Kelly wrote:
>     So for version and operationtype, enum is ok. These originate at the client, so if the servers are always upgraded at the client, there's no interoperability issues. Status codes originate at the server though, so it is possible for the server to send a statuscode that is unrecognised to a client. The normal way to handle this would be a "else" or "default:" to pass this up to the client as a BKException.UnexpectedConditionException. If it's an enum, this will throw a decode exception in the netty decoder, which is harder to handle.
>     
>     To resolve this on the server side, by checking the version and only sending errors valid for that version, implies two things. Firstly, every error code change will require the version to be bumped and secondly, that there will need to be a list maintained for which errors are valid for each version. This goes against the motivation for using protobuf in the first place.
> 
> Sijie Guo wrote:
>     this is the application level agreement, no? it doesn't matter that u are using a protobuf protocol or using current protocol, or it also doesn't matter that u are using an integer or an enum. in any case, the best way is as you described, you shouldn't send new status code back to an old client, as the new status code is meaningless to the old client.
> 
> Ivan Kelly wrote:
>     but how do you know its an old client? Only by bumping the version number each time you add an error code. In which case you end up with a whole lot of junk like "if (client.version == X) { send A } else if (client.version == Y) { send B } else if (client.version ..." which is exactly what protobuf was designed to avoid (see "A bit of history" on https://developers.google.com/protocol-buffers/docs/overview).
> 
> Sijie Guo wrote:
>     a else or default branch would make the behavior unpredictable as an old client is treating a new status code as some kind of unknown. as you said, you want to treat them as UnexpectedConditionException. But what does UnexpectedConditionException means? doesn't it mean the sever already breaks backward compatibility, since server couldn't satisfy the old client's request.
>     
>     so still, if server wants to be backward compatibility to clients, in any cases, it needs to know what version of protocol that the client is speaking and handle them accordingly, not just let client to do their job in an unexpected way.
>     
>     I don't see any elegant solutions without detecting protocol version. if you have, please describe how not being enum would avoid this.
> 
> Ivan Kelly wrote:
>     the default behaviour for an unknown error code is something we already use today.
>     https://github.com/apache/bookkeeper/blob/trunk/bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PerChannelBookieClient.java#L714
>     
>     The client only needs to know that the request failed. the point of the different error codes is so that the client could take specific recovery steps. the default behaviour is just to pass the error up.
> 
> Sijie Guo wrote:
>     the default behavior was there just for all already known status codes. but it doesn't mean it is correct for any unknown status codes. and when u are saying 'the client only needs to know that the request failed', you are making an assumption that there is only one status code indicating OK, other status code should be taken as failed. but it isn't true. say in an old protocol, we supported range reads, it responded with OK, list of entry response (0 = <data>, 1 = missing, 2 = missing, 3 = <data>). if we are going to improve our protocol to make communication more efficient, we are going to change the protocol to get rid of transferring missing entries: responding with PARTIAL_OK, list of existing entries (0 = <data>, 3 = <data>). 
>     
>     in this case, if server doesn't distinguish the client's protocol, just respond every range reads with PARTIAL_OK, would did break the compatibility with old protocol, as old protocol treats it as failure by default behavior. in order to maintain backward compatibility, server needs to detect the client's protocol and responds accordingly. as what I said, for backward compatibility, a protocol doesn't really help if it involves behavior in application agreement. and a default behavior is not exact right.
>     
>     for me, using protocol. it means that it is easy for us to add new requests type, add new fields in existing requests. besides that, we need to keep the backward compatibility in our level.
> 
> Ivan Kelly wrote:
>     when i say that 'the client only needs to know that the request failed', it means that the client only needs to recognise the statuses which indicate success. for any request, the status codes which indicate success should never change. For a read request or add request, only OK is SUCCESS. For range read,  only PARTIAL_OK and OK are success. But the client will never send a range read request unless it already knows about PARTIAL_OK.
> 
> Sijie Guo wrote:
>     > “But the client will never send a range read request unless it already knows about PARTIAL_OK.” 
>     
>     the example that I made is that the range read introduced with OK, but if it is going to evolved to have PARTIAL_OK. then that will be an problem.

Partial_ok doesn't make sense if you're using the concept of packet status and operation status (as mentioned below).


- Ivan


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/17895/#review41130
-----------------------------------------------------------


On April 24, 2014, 7:43 a.m., Sijie Guo wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/17895/
> -----------------------------------------------------------
> 
> (Updated April 24, 2014, 7:43 a.m.)
> 
> 
> Review request for bookkeeper and Ivan Kelly.
> 
> 
> Bugs: BOOKKEEPER-582
>     https://issues.apache.org/jira/browse/BOOKKEEPER-582
> 
> 
> Repository: bookkeeper-git
> 
> 
> Description
> -------
> 
> - introducing protobuf support for bookkeeper
> - for server: introduce packet processor / EnDecoder for different protocol supports
> - for client: change PCBC to use protobuf to send requests
> - misc changes for protobuf support
> 
> (bookie server is able for backward compatibility) 
> 
> 
> Diffs
> -----
> 
>   bookkeeper-server/pom.xml ebc1198 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/bookie/IndexInMemPageMgr.java 56487aa 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/LedgerChecker.java 28e23d6 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/PendingReadOp.java fb36b90 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/processor/RequestProcessor.java 241f369 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieProtoEncoding.java 1154047 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestHandler.java b922a82 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestProcessor.java 8155b22 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookkeeperProtocol.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBase.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBaseV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PerChannelBookieClient.java a10f7d5 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/proto/BookkeeperProtocol.proto PRE-CREATION 
>   bookkeeper-server/src/main/resources/findbugsExclude.xml 97a6156 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/proto/TestProtoVersions.java 5fcc445 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/replication/AuditorPeriodicCheckTest.java 3f8496f 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/BookieClientTest.java bc05229 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/TestBackwardCompat.java 8376b46 
>   compat-deps/bookkeeper-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/hedwig-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/pom.xml f79582d 
>   hedwig-server/pom.xml 06cf01c 
>   hedwig-server/src/test/java/org/apache/hedwig/server/TestBackwardCompat.java 8da109e 
> 
> Diff: https://reviews.apache.org/r/17895/diff/
> 
> 
> Testing
> -------
> 
> unit tests. backward tests.
> 
> 
> Thanks,
> 
> Sijie Guo
> 
>

Re: Review Request 17895: BOOKKEEPER-582: protobuf support for bookkeeper

Posted by Ivan Kelly <iv...@apache.org>.


> On April 23, 2014, 10:22 a.m., Ivan Kelly wrote:
> >
> 
> Sijie Guo wrote:
>     ok. let me step back. how bad is the current protocol? if no, why we keep arguing on this? as those changes will break our system, then I don't see the value of contributing our patches back to the community.
> 
> Ivan Kelly wrote:
>     For me, the motivating change was auth. The initial drop I did for auth[1] was based in PB to allow for auth providers to include their own extensions with PB and not have to deal with parsing. This was mixing old parsing and PB though, so I held off the change until PB went in, so that we wouldnt have two parsing mechanisms being actively developed.
>     
>     For me, this motivation is still valid. Having two decoding mechanisms is ugly and hacky. With the plan to add batch reads,it also makes sense to be easily able to add messages.
>     
>     Another motivation is to reduce the variation between the branches. We currently have 3 branchs, the apache branch, the twitter branch and the yahoo branch (perhaps huawei also have a branch). These will unlikely ever be 100% identical, but I had hoped that we could keep the difference to a minimum to allow for us to be able to benefit from each others changes.
>     
>     That said, changes from all sides need to go through the full review process before going in. Both companies have different production usecases, roadmaps, and rollout mechanisms, so assumptions may not hold across organisations.
>     
>     To bring it back to the current patch, and your initial question, the current protocol isn't terrible. The code for it is a hell of a lot cleaner than it was 2 years ago. However, it's cumbersome to add anything to the protocol, mostly because of decisions taken early on, (such as the difference in position of ledgerid and entryid in read and add requests). I was hoping we could avoid locking ourselves into something like this again. 
>     
>     [1] https://github.com/ivankelly/bookkeeper/commits/BookKeeperAuth
> 
> Sijie Guo wrote:
>     ok. replies on your individual concerns.

We seem to be going round in circles here. I've replied below. But to compromise on somethings, if you change the flags and only have double statuses for responses that need them (i.e. add an intermediate message), I can live with enum status codes, operationType and a whole lot of stuff being required when it should be optional. If you make those changes, Ill push the commit. Otherwise, we need to bring in a tiebreaker.


> On April 23, 2014, 10:22 a.m., Ivan Kelly wrote:
> > bookkeeper-server/src/main/proto/BookkeeperProtocol.proto, line 33
> > <https://reviews.apache.org/r/17895/diff/2/?file=563033#file563033line33>
> >
> >     This should certainly not be an enum. Otherwise we need to bump the protocol version each time we add an error code.
> >     
> >     Imagine the scenario where both server and client are running 4.3.0. Then the server is upgraded with 4.3.1 which a new error EPRINTERONFIRE. It sends this to the client who throws a decode error.
> 
> Sijie Guo wrote:
>     how could being not enum help this? if it is integer, client still has no idea how to interpret, so it is still invalid response from 4.3.0 client. I thought we reached an agreement on enum on the ticket, no?
> 
> Ivan Kelly wrote:
>     So for version and operationtype, enum is ok. These originate at the client, so if the servers are always upgraded at the client, there's no interoperability issues. Status codes originate at the server though, so it is possible for the server to send a statuscode that is unrecognised to a client. The normal way to handle this would be a "else" or "default:" to pass this up to the client as a BKException.UnexpectedConditionException. If it's an enum, this will throw a decode exception in the netty decoder, which is harder to handle.
>     
>     To resolve this on the server side, by checking the version and only sending errors valid for that version, implies two things. Firstly, every error code change will require the version to be bumped and secondly, that there will need to be a list maintained for which errors are valid for each version. This goes against the motivation for using protobuf in the first place.
> 
> Sijie Guo wrote:
>     this is the application level agreement, no? it doesn't matter that u are using a protobuf protocol or using current protocol, or it also doesn't matter that u are using an integer or an enum. in any case, the best way is as you described, you shouldn't send new status code back to an old client, as the new status code is meaningless to the old client.
> 
> Ivan Kelly wrote:
>     but how do you know its an old client? Only by bumping the version number each time you add an error code. In which case you end up with a whole lot of junk like "if (client.version == X) { send A } else if (client.version == Y) { send B } else if (client.version ..." which is exactly what protobuf was designed to avoid (see "A bit of history" on https://developers.google.com/protocol-buffers/docs/overview).
> 
> Sijie Guo wrote:
>     a else or default branch would make the behavior unpredictable as an old client is treating a new status code as some kind of unknown. as you said, you want to treat them as UnexpectedConditionException. But what does UnexpectedConditionException means? doesn't it mean the sever already breaks backward compatibility, since server couldn't satisfy the old client's request.
>     
>     so still, if server wants to be backward compatibility to clients, in any cases, it needs to know what version of protocol that the client is speaking and handle them accordingly, not just let client to do their job in an unexpected way.
>     
>     I don't see any elegant solutions without detecting protocol version. if you have, please describe how not being enum would avoid this.
> 
> Ivan Kelly wrote:
>     the default behaviour for an unknown error code is something we already use today.
>     https://github.com/apache/bookkeeper/blob/trunk/bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PerChannelBookieClient.java#L714
>     
>     The client only needs to know that the request failed. the point of the different error codes is so that the client could take specific recovery steps. the default behaviour is just to pass the error up.
> 
> Sijie Guo wrote:
>     the default behavior was there just for all already known status codes. but it doesn't mean it is correct for any unknown status codes. and when u are saying 'the client only needs to know that the request failed', you are making an assumption that there is only one status code indicating OK, other status code should be taken as failed. but it isn't true. say in an old protocol, we supported range reads, it responded with OK, list of entry response (0 = <data>, 1 = missing, 2 = missing, 3 = <data>). if we are going to improve our protocol to make communication more efficient, we are going to change the protocol to get rid of transferring missing entries: responding with PARTIAL_OK, list of existing entries (0 = <data>, 3 = <data>). 
>     
>     in this case, if server doesn't distinguish the client's protocol, just respond every range reads with PARTIAL_OK, would did break the compatibility with old protocol, as old protocol treats it as failure by default behavior. in order to maintain backward compatibility, server needs to detect the client's protocol and responds accordingly. as what I said, for backward compatibility, a protocol doesn't really help if it involves behavior in application agreement. and a default behavior is not exact right.
>     
>     for me, using protocol. it means that it is easy for us to add new requests type, add new fields in existing requests. besides that, we need to keep the backward compatibility in our level.

when i say that 'the client only needs to know that the request failed', it means that the client only needs to recognise the statuses which indicate success. for any request, the status codes which indicate success should never change. For a read request or add request, only OK is SUCCESS. For range read,  only PARTIAL_OK and OK are success. But the client will never send a range read request unless it already knows about PARTIAL_OK.


> On April 23, 2014, 10:22 a.m., Ivan Kelly wrote:
> > bookkeeper-server/src/main/proto/BookkeeperProtocol.proto, line 65
> > <https://reviews.apache.org/r/17895/diff/2/?file=563033#file563033line65>
> >
> >     Comment 1.
> >     OperationType is redundant. The server can do #hasReadRequest and #hasAddRequest to check the request to check the type. We shouldn't send redundant data over the wire where possible.
> >     
> >     Comment 2.
> >     it better to make the absolute minimum to be required. Required is forever, and these may not be.
> >     
> >     https://developers.google.com/protocol-buffers/docs/proto
> >
> 
> Sijie Guo wrote:
>     > comment 1.
>     
>     OperationType will make request more clear and specify and less if...else branches. And OperationType is used for PCBC to unify all requests handling. so we don't need to have individual maps to maintain requests each time we added a new type of requests.
>     
>     > comment 2.
>     
>     if reply to comment 1 works for u, I don't see any reason why operation would not be a required.
> 
> Ivan Kelly wrote:
>     Ok. I can live with it, though I still think it's a little cumbersome. Regarding requiredness, I still think it should be optional. All fields should be optional by default to give you as much freedom to evolve the protocol in the future as possible. Especially something, which is not 100% essential to the protocol, like this field.
> 
> Sijie Guo wrote:
>     for those fields that already exist in the origin protocol, I don't see we are going to remove them. that's why we put it as required.
> 
> Ivan Kelly wrote:
>     We shouldnt prelude the possibility though. What problem could making them optional cause?
> 
> Sijie Guo wrote:
>     what does an response w/o OperationType mean? How PCBC would handle this? as I said, OperationType is somehow guiding us to dispatch the request and response. so it is required.
> 
> Ivan Kelly wrote:
>     the operation type can be inferred from the contents as i said already. So OperationType itself isnt actually required, so we should lock it in at this point.
> 
> Sijie Guo wrote:
>     say you have A, B, C types of requests, you have resp_A, resp_B, resp_C optional fields in response. if using OperationType, you explicitly know what response that the request is for. it reduce the branches that u need to check if the response is valid or not: for example, for response A, it just need to check if resp_A exists or not. if not, it is an invalid response for A. you don't need to touch resp_B and resp_C.
>     
>     if OperationType is not used, you need to write lots of if..else branches to identify what's the response for. e.g. hasResp_A & !hasResp_B & !hasResp_C is for request type A. even worser, if you are adding new request type, you need to change all the if...else branches.

You dont need to check all negative cases. But thats beside the point. My point is that it is conceivable to not have operationType, even though im ok will it going through with this patch, and since it is conceivable for it to be absent, we should leave open the possibility by making it optional.


> On April 23, 2014, 10:22 a.m., Ivan Kelly wrote:
> > bookkeeper-server/src/main/proto/BookkeeperProtocol.proto, line 80
> > <https://reviews.apache.org/r/17895/diff/2/?file=563033#file563033line80>
> >
> >     This would be better served with a boolean. protobuf will keep it compact.
> 
> Sijie Guo wrote:
>     being Flag will make it easier to add other flags in future.
> 
> Ivan Kelly wrote:
>     No it doesn't. Lets say you do add another flag in the future. How do you specify that it's both a FENCE_LEDGER and NEW_FLAG? You need the field to be repeated, and then you need code to loop through the flags. Compared to msg.isFenceLedger(), this seems much more cumbersome.
> 
> Sijie Guo wrote:
>     I don't say this field is bits-set-like of flags. as the long poll changes we mentioned, we are going to add a new flag 'ENTRY_PIGGYBACK' for read. so a read request is either a normal read (without Flag), a fence read (flag = FENCE_LEDGER) or a piggyback read (flag = ENTRY_PIGGYBACK). Being repeated will be kind of complicated, as you need to loop all possible permutation.
> 
> Ivan Kelly wrote:
>     This is ugly and shortsighted. There may well be a case in the future where two flags need to be specified. What do we do then? Add a flags2 field?
> 
> Sijie Guo wrote:
>     why this couldn't be a 3rd flag? FENCE_LEDGER_AND_PIGGYBACK?
>     
>     in your repeated way, let's say you have n flags, you would have n! ways to combine them. it is hard to figure out what kind of combination works for what situation. as some of your flags are exclusive with others. so renaming the combination specifically would make it clear.
> 
> Ivan Kelly wrote:
>     as you say, with n flags specified, there are n! combinations. so if another flag as added, you will have to add n values to the enum to cover the different combinations. whether the flags are exclusive is for the application to decide. it shouldnt be implicit in the protocol encoding.
> 
> Sijie Guo wrote:
>     same explanation for OperationType is applying here. if n flags mostly are used individually, an explicit way will just need to deal with around n possibilities. but you need to write lots of if..else branches for inferring in an implicit way.

Your assumption here is that all the flag handling code will be in one place in a big switch. this isnt the case. I dont know how you have implemented piggyback, but i would guess it would be something like.

Response processReadRequest(Request req) {
    if (isFencing(req)) {
        fenceLedger();
    }
    byte[] data = fetchEntry(req.getLedgerId(), req.getEntryId());
    Response resp = new Response(OK, data);
    if (isPiggyback(req)) {
        addPiggyback(resp);
    }
    return resp;
}

Now consider how #isPiggyback and #isFencing would be implemented with enums and with individual boolean flags? which is shorter? Which is easier to maintain?


- Ivan


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/17895/#review41130
-----------------------------------------------------------


On April 24, 2014, 7:43 a.m., Sijie Guo wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/17895/
> -----------------------------------------------------------
> 
> (Updated April 24, 2014, 7:43 a.m.)
> 
> 
> Review request for bookkeeper and Ivan Kelly.
> 
> 
> Bugs: BOOKKEEPER-582
>     https://issues.apache.org/jira/browse/BOOKKEEPER-582
> 
> 
> Repository: bookkeeper-git
> 
> 
> Description
> -------
> 
> - introducing protobuf support for bookkeeper
> - for server: introduce packet processor / EnDecoder for different protocol supports
> - for client: change PCBC to use protobuf to send requests
> - misc changes for protobuf support
> 
> (bookie server is able for backward compatibility) 
> 
> 
> Diffs
> -----
> 
>   bookkeeper-server/pom.xml ebc1198 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/bookie/IndexInMemPageMgr.java 56487aa 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/LedgerChecker.java 28e23d6 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/PendingReadOp.java fb36b90 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/processor/RequestProcessor.java 241f369 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieProtoEncoding.java 1154047 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestHandler.java b922a82 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestProcessor.java 8155b22 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookkeeperProtocol.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBase.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBaseV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PerChannelBookieClient.java a10f7d5 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/proto/BookkeeperProtocol.proto PRE-CREATION 
>   bookkeeper-server/src/main/resources/findbugsExclude.xml 97a6156 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/proto/TestProtoVersions.java 5fcc445 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/replication/AuditorPeriodicCheckTest.java 3f8496f 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/BookieClientTest.java bc05229 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/TestBackwardCompat.java 8376b46 
>   compat-deps/bookkeeper-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/hedwig-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/pom.xml f79582d 
>   hedwig-server/pom.xml 06cf01c 
>   hedwig-server/src/test/java/org/apache/hedwig/server/TestBackwardCompat.java 8da109e 
> 
> Diff: https://reviews.apache.org/r/17895/diff/
> 
> 
> Testing
> -------
> 
> unit tests. backward tests.
> 
> 
> Thanks,
> 
> Sijie Guo
> 
>

Re: Review Request 17895: BOOKKEEPER-582: protobuf support for bookkeeper

Posted by Sijie Guo <gu...@gmail.com>.


> On April 23, 2014, 10:22 a.m., Ivan Kelly wrote:
> > bookkeeper-server/src/main/proto/BookkeeperProtocol.proto, line 33
> > <https://reviews.apache.org/r/17895/diff/2/?file=563033#file563033line33>
> >
> >     This should certainly not be an enum. Otherwise we need to bump the protocol version each time we add an error code.
> >     
> >     Imagine the scenario where both server and client are running 4.3.0. Then the server is upgraded with 4.3.1 which a new error EPRINTERONFIRE. It sends this to the client who throws a decode error.
> 
> Sijie Guo wrote:
>     how could being not enum help this? if it is integer, client still has no idea how to interpret, so it is still invalid response from 4.3.0 client. I thought we reached an agreement on enum on the ticket, no?
> 
> Ivan Kelly wrote:
>     So for version and operationtype, enum is ok. These originate at the client, so if the servers are always upgraded at the client, there's no interoperability issues. Status codes originate at the server though, so it is possible for the server to send a statuscode that is unrecognised to a client. The normal way to handle this would be a "else" or "default:" to pass this up to the client as a BKException.UnexpectedConditionException. If it's an enum, this will throw a decode exception in the netty decoder, which is harder to handle.
>     
>     To resolve this on the server side, by checking the version and only sending errors valid for that version, implies two things. Firstly, every error code change will require the version to be bumped and secondly, that there will need to be a list maintained for which errors are valid for each version. This goes against the motivation for using protobuf in the first place.
> 
> Sijie Guo wrote:
>     this is the application level agreement, no? it doesn't matter that u are using a protobuf protocol or using current protocol, or it also doesn't matter that u are using an integer or an enum. in any case, the best way is as you described, you shouldn't send new status code back to an old client, as the new status code is meaningless to the old client.
> 
> Ivan Kelly wrote:
>     but how do you know its an old client? Only by bumping the version number each time you add an error code. In which case you end up with a whole lot of junk like "if (client.version == X) { send A } else if (client.version == Y) { send B } else if (client.version ..." which is exactly what protobuf was designed to avoid (see "A bit of history" on https://developers.google.com/protocol-buffers/docs/overview).
> 
> Sijie Guo wrote:
>     a else or default branch would make the behavior unpredictable as an old client is treating a new status code as some kind of unknown. as you said, you want to treat them as UnexpectedConditionException. But what does UnexpectedConditionException means? doesn't it mean the sever already breaks backward compatibility, since server couldn't satisfy the old client's request.
>     
>     so still, if server wants to be backward compatibility to clients, in any cases, it needs to know what version of protocol that the client is speaking and handle them accordingly, not just let client to do their job in an unexpected way.
>     
>     I don't see any elegant solutions without detecting protocol version. if you have, please describe how not being enum would avoid this.
> 
> Ivan Kelly wrote:
>     the default behaviour for an unknown error code is something we already use today.
>     https://github.com/apache/bookkeeper/blob/trunk/bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PerChannelBookieClient.java#L714
>     
>     The client only needs to know that the request failed. the point of the different error codes is so that the client could take specific recovery steps. the default behaviour is just to pass the error up.
> 
> Sijie Guo wrote:
>     the default behavior was there just for all already known status codes. but it doesn't mean it is correct for any unknown status codes. and when u are saying 'the client only needs to know that the request failed', you are making an assumption that there is only one status code indicating OK, other status code should be taken as failed. but it isn't true. say in an old protocol, we supported range reads, it responded with OK, list of entry response (0 = <data>, 1 = missing, 2 = missing, 3 = <data>). if we are going to improve our protocol to make communication more efficient, we are going to change the protocol to get rid of transferring missing entries: responding with PARTIAL_OK, list of existing entries (0 = <data>, 3 = <data>). 
>     
>     in this case, if server doesn't distinguish the client's protocol, just respond every range reads with PARTIAL_OK, would did break the compatibility with old protocol, as old protocol treats it as failure by default behavior. in order to maintain backward compatibility, server needs to detect the client's protocol and responds accordingly. as what I said, for backward compatibility, a protocol doesn't really help if it involves behavior in application agreement. and a default behavior is not exact right.
>     
>     for me, using protocol. it means that it is easy for us to add new requests type, add new fields in existing requests. besides that, we need to keep the backward compatibility in our level.
> 
> Ivan Kelly wrote:
>     when i say that 'the client only needs to know that the request failed', it means that the client only needs to recognise the statuses which indicate success. for any request, the status codes which indicate success should never change. For a read request or add request, only OK is SUCCESS. For range read,  only PARTIAL_OK and OK are success. But the client will never send a range read request unless it already knows about PARTIAL_OK.
> 
> Sijie Guo wrote:
>     > “But the client will never send a range read request unless it already knows about PARTIAL_OK.” 
>     
>     the example that I made is that the range read introduced with OK, but if it is going to evolved to have PARTIAL_OK. then that will be an problem.
> 
> Ivan Kelly wrote:
>     Partial_ok doesn't make sense if you're using the concept of packet status and operation status (as mentioned below).
> 
> Sijie Guo wrote:
>     well, if u are talking about a specific case (e.g. range read), I might agree with u. but if you read my comments, it is just the case that I explained how the protocol might be evolved. And my point is and always will be for backward compatibility, the server shouldn't send any unknown codes/fields back to clients that speaks old protocol, this is part of application-level agreement, no matter using enum or integer.
> 
> Rakesh R wrote:
>     Using enum is more readable and would be good for newcomers too. Assume a case where we are introducing new EC for an existing request type at the side server side, EC#NEW_ERR_CODE in 4.3.1 and client is old one 4.3.0. Ideally in this case, bk client should say its unknown code.
>     
>     Does this create any parsing issues at the protobuf ?. If not, I'm OK using enum for the StatusCode too.
> 
> Sijie Guo wrote:
>     if you read the conversation about this, my point is that for correct backward compatibility, we should avoid sending unknown error codes back to an old client.
> 
> Rakesh R wrote:
>     So server should have version specific checks and generates the error codes, isn't it ?.

yes. exact as what I pointed. sending responses matching exact version of protocol, isn't that exactly for application level backward compatible? why this would be the concern?


- Sijie


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/17895/#review41130
-----------------------------------------------------------


On April 24, 2014, 7:43 a.m., Sijie Guo wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/17895/
> -----------------------------------------------------------
> 
> (Updated April 24, 2014, 7:43 a.m.)
> 
> 
> Review request for bookkeeper and Ivan Kelly.
> 
> 
> Bugs: BOOKKEEPER-582
>     https://issues.apache.org/jira/browse/BOOKKEEPER-582
> 
> 
> Repository: bookkeeper-git
> 
> 
> Description
> -------
> 
> - introducing protobuf support for bookkeeper
> - for server: introduce packet processor / EnDecoder for different protocol supports
> - for client: change PCBC to use protobuf to send requests
> - misc changes for protobuf support
> 
> (bookie server is able for backward compatibility) 
> 
> 
> Diffs
> -----
> 
>   bookkeeper-server/pom.xml ebc1198 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/bookie/IndexInMemPageMgr.java 56487aa 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/LedgerChecker.java 28e23d6 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/PendingReadOp.java fb36b90 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/processor/RequestProcessor.java 241f369 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieProtoEncoding.java 1154047 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestHandler.java b922a82 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestProcessor.java 8155b22 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookkeeperProtocol.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBase.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBaseV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PerChannelBookieClient.java a10f7d5 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/proto/BookkeeperProtocol.proto PRE-CREATION 
>   bookkeeper-server/src/main/resources/findbugsExclude.xml 97a6156 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/proto/TestProtoVersions.java 5fcc445 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/replication/AuditorPeriodicCheckTest.java 3f8496f 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/BookieClientTest.java bc05229 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/TestBackwardCompat.java 8376b46 
>   compat-deps/bookkeeper-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/hedwig-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/pom.xml f79582d 
>   hedwig-server/pom.xml 06cf01c 
>   hedwig-server/src/test/java/org/apache/hedwig/server/TestBackwardCompat.java 8da109e 
> 
> Diff: https://reviews.apache.org/r/17895/diff/
> 
> 
> Testing
> -------
> 
> unit tests. backward tests.
> 
> 
> Thanks,
> 
> Sijie Guo
> 
>

Re: Review Request 17895: BOOKKEEPER-582: protobuf support for bookkeeper

Posted by Sijie Guo <gu...@gmail.com>.


> On April 23, 2014, 10:22 a.m., Ivan Kelly wrote:
> > bookkeeper-server/src/main/java/org/apache/bookkeeper/client/LedgerChecker.java, line 131
> > <https://reviews.apache.org/r/17895/diff/2/?file=563019#file563019line131>
> >
> >     This change seems unrelated. I don't mind it going in, but could you give some background as to why it's here?

we want to specifically call out when read entry fails for ledger not existing. so in the application, some cases that handling for NoSuchLedgerExists and NoSuchEntryExists maybe identical, so we could let the caller decide how they want to differentiate these exceptions.


> On April 23, 2014, 10:22 a.m., Ivan Kelly wrote:
> > bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestProcessor.java, line 129
> > <https://reviews.apache.org/r/17895/diff/2/?file=563024#file563024line129>
> >
> >     typo

will fix


> On April 23, 2014, 10:22 a.m., Ivan Kelly wrote:
> > bookkeeper-server/src/main/proto/BookkeeperProtocol.proto, line 33
> > <https://reviews.apache.org/r/17895/diff/2/?file=563033#file563033line33>
> >
> >     This should certainly not be an enum. Otherwise we need to bump the protocol version each time we add an error code.
> >     
> >     Imagine the scenario where both server and client are running 4.3.0. Then the server is upgraded with 4.3.1 which a new error EPRINTERONFIRE. It sends this to the client who throws a decode error.

how could being not enum help this? if it is integer, client still has no idea how to interpret, so it is still invalid response from 4.3.0 client. I thought we reached an agreement on enum on the ticket, no?


> On April 23, 2014, 10:22 a.m., Ivan Kelly wrote:
> > bookkeeper-server/src/main/proto/BookkeeperProtocol.proto, line 65
> > <https://reviews.apache.org/r/17895/diff/2/?file=563033#file563033line65>
> >
> >     Comment 1.
> >     OperationType is redundant. The server can do #hasReadRequest and #hasAddRequest to check the request to check the type. We shouldn't send redundant data over the wire where possible.
> >     
> >     Comment 2.
> >     it better to make the absolute minimum to be required. Required is forever, and these may not be.
> >     
> >     https://developers.google.com/protocol-buffers/docs/proto
> >

> comment 1.

OperationType will make request more clear and specify and less if...else branches. And OperationType is used for PCBC to unify all requests handling. so we don't need to have individual maps to maintain requests each time we added a new type of requests.

> comment 2.

if reply to comment 1 works for u, I don't see any reason why operation would not be a required.


> On April 23, 2014, 10:22 a.m., Ivan Kelly wrote:
> > bookkeeper-server/src/main/proto/BookkeeperProtocol.proto, line 80
> > <https://reviews.apache.org/r/17895/diff/2/?file=563033#file563033line80>
> >
> >     This would be better served with a boolean. protobuf will keep it compact.

being Flag will make it easier to add other flags in future.


> On April 23, 2014, 10:22 a.m., Ivan Kelly wrote:
> > bookkeeper-server/src/main/proto/BookkeeperProtocol.proto, line 92
> > <https://reviews.apache.org/r/17895/diff/2/?file=563033#file563033line92>
> >
> >     same as fenced, better as boolean

same as previous comment.


> On April 23, 2014, 10:22 a.m., Ivan Kelly wrote:
> > bookkeeper-server/src/main/proto/BookkeeperProtocol.proto, line 104
> > <https://reviews.apache.org/r/17895/diff/2/?file=563033#file563033line104>
> >
> >     You're sending StatusCode twice, every time. Firstly, shouldn't be an enum as stated above. Secondly, shouldn't be required.

> enum

as the comments above.

> status code twice.

the status code for ReadResponse/AddResponse is for individual responses. if we are going to support kind of batch reads, the status code of Response means either the whole batch succeed or not while the individual read responses might have different status codes (e.g OK or NotExists). That is why it exists two places.

> required

as the comments above


- Sijie


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/17895/#review41130
-----------------------------------------------------------


On April 21, 2014, 5:58 a.m., Sijie Guo wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/17895/
> -----------------------------------------------------------
> 
> (Updated April 21, 2014, 5:58 a.m.)
> 
> 
> Review request for bookkeeper and Ivan Kelly.
> 
> 
> Bugs: BOOKKEEPER-582
>     https://issues.apache.org/jira/browse/BOOKKEEPER-582
> 
> 
> Repository: bookkeeper-git
> 
> 
> Description
> -------
> 
> - introducing protobuf support for bookkeeper
> - for server: introduce packet processor / EnDecoder for different protocol supports
> - for client: change PCBC to use protobuf to send requests
> - misc changes for protobuf support
> 
> (bookie server is able for backward compatibility) 
> 
> 
> Diffs
> -----
> 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/bookie/IndexInMemPageMgr.java 56487aa 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/LedgerChecker.java 28e23d6 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/PendingReadOp.java fb36b90 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/processor/RequestProcessor.java 241f369 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieProtoEncoding.java 1154047 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestHandler.java b922a82 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestProcessor.java 8155b22 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookkeeperProtocol.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBase.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBaseV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PerChannelBookieClient.java a10f7d5 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/proto/BookkeeperProtocol.proto PRE-CREATION 
>   bookkeeper-server/src/main/resources/findbugsExclude.xml 97a6156 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/proto/TestProtoVersions.java 5fcc445 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/replication/AuditorPeriodicCheckTest.java 3f8496f 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/BookieClientTest.java bc05229 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/TestBackwardCompat.java 8376b46 
> 
> Diff: https://reviews.apache.org/r/17895/diff/
> 
> 
> Testing
> -------
> 
> unit tests. backward tests.
> 
> 
> Thanks,
> 
> Sijie Guo
> 
>

Re: Review Request 17895: BOOKKEEPER-582: protobuf support for bookkeeper

Posted by Rakesh R <ra...@huawei.com>.


> On April 23, 2014, 10:22 a.m., Ivan Kelly wrote:
> > bookkeeper-server/src/main/proto/BookkeeperProtocol.proto, line 33
> > <https://reviews.apache.org/r/17895/diff/2/?file=563033#file563033line33>
> >
> >     This should certainly not be an enum. Otherwise we need to bump the protocol version each time we add an error code.
> >     
> >     Imagine the scenario where both server and client are running 4.3.0. Then the server is upgraded with 4.3.1 which a new error EPRINTERONFIRE. It sends this to the client who throws a decode error.
> 
> Sijie Guo wrote:
>     how could being not enum help this? if it is integer, client still has no idea how to interpret, so it is still invalid response from 4.3.0 client. I thought we reached an agreement on enum on the ticket, no?
> 
> Ivan Kelly wrote:
>     So for version and operationtype, enum is ok. These originate at the client, so if the servers are always upgraded at the client, there's no interoperability issues. Status codes originate at the server though, so it is possible for the server to send a statuscode that is unrecognised to a client. The normal way to handle this would be a "else" or "default:" to pass this up to the client as a BKException.UnexpectedConditionException. If it's an enum, this will throw a decode exception in the netty decoder, which is harder to handle.
>     
>     To resolve this on the server side, by checking the version and only sending errors valid for that version, implies two things. Firstly, every error code change will require the version to be bumped and secondly, that there will need to be a list maintained for which errors are valid for each version. This goes against the motivation for using protobuf in the first place.
> 
> Sijie Guo wrote:
>     this is the application level agreement, no? it doesn't matter that u are using a protobuf protocol or using current protocol, or it also doesn't matter that u are using an integer or an enum. in any case, the best way is as you described, you shouldn't send new status code back to an old client, as the new status code is meaningless to the old client.
> 
> Ivan Kelly wrote:
>     but how do you know its an old client? Only by bumping the version number each time you add an error code. In which case you end up with a whole lot of junk like "if (client.version == X) { send A } else if (client.version == Y) { send B } else if (client.version ..." which is exactly what protobuf was designed to avoid (see "A bit of history" on https://developers.google.com/protocol-buffers/docs/overview).
> 
> Sijie Guo wrote:
>     a else or default branch would make the behavior unpredictable as an old client is treating a new status code as some kind of unknown. as you said, you want to treat them as UnexpectedConditionException. But what does UnexpectedConditionException means? doesn't it mean the sever already breaks backward compatibility, since server couldn't satisfy the old client's request.
>     
>     so still, if server wants to be backward compatibility to clients, in any cases, it needs to know what version of protocol that the client is speaking and handle them accordingly, not just let client to do their job in an unexpected way.
>     
>     I don't see any elegant solutions without detecting protocol version. if you have, please describe how not being enum would avoid this.
> 
> Ivan Kelly wrote:
>     the default behaviour for an unknown error code is something we already use today.
>     https://github.com/apache/bookkeeper/blob/trunk/bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PerChannelBookieClient.java#L714
>     
>     The client only needs to know that the request failed. the point of the different error codes is so that the client could take specific recovery steps. the default behaviour is just to pass the error up.
> 
> Sijie Guo wrote:
>     the default behavior was there just for all already known status codes. but it doesn't mean it is correct for any unknown status codes. and when u are saying 'the client only needs to know that the request failed', you are making an assumption that there is only one status code indicating OK, other status code should be taken as failed. but it isn't true. say in an old protocol, we supported range reads, it responded with OK, list of entry response (0 = <data>, 1 = missing, 2 = missing, 3 = <data>). if we are going to improve our protocol to make communication more efficient, we are going to change the protocol to get rid of transferring missing entries: responding with PARTIAL_OK, list of existing entries (0 = <data>, 3 = <data>). 
>     
>     in this case, if server doesn't distinguish the client's protocol, just respond every range reads with PARTIAL_OK, would did break the compatibility with old protocol, as old protocol treats it as failure by default behavior. in order to maintain backward compatibility, server needs to detect the client's protocol and responds accordingly. as what I said, for backward compatibility, a protocol doesn't really help if it involves behavior in application agreement. and a default behavior is not exact right.
>     
>     for me, using protocol. it means that it is easy for us to add new requests type, add new fields in existing requests. besides that, we need to keep the backward compatibility in our level.
> 
> Ivan Kelly wrote:
>     when i say that 'the client only needs to know that the request failed', it means that the client only needs to recognise the statuses which indicate success. for any request, the status codes which indicate success should never change. For a read request or add request, only OK is SUCCESS. For range read,  only PARTIAL_OK and OK are success. But the client will never send a range read request unless it already knows about PARTIAL_OK.
> 
> Sijie Guo wrote:
>     > “But the client will never send a range read request unless it already knows about PARTIAL_OK.” 
>     
>     the example that I made is that the range read introduced with OK, but if it is going to evolved to have PARTIAL_OK. then that will be an problem.
> 
> Ivan Kelly wrote:
>     Partial_ok doesn't make sense if you're using the concept of packet status and operation status (as mentioned below).
> 
> Sijie Guo wrote:
>     well, if u are talking about a specific case (e.g. range read), I might agree with u. but if you read my comments, it is just the case that I explained how the protocol might be evolved. And my point is and always will be for backward compatibility, the server shouldn't send any unknown codes/fields back to clients that speaks old protocol, this is part of application-level agreement, no matter using enum or integer.
> 
> Rakesh R wrote:
>     Using enum is more readable and would be good for newcomers too. Assume a case where we are introducing new EC for an existing request type at the side server side, EC#NEW_ERR_CODE in 4.3.1 and client is old one 4.3.0. Ideally in this case, bk client should say its unknown code.
>     
>     Does this create any parsing issues at the protobuf ?. If not, I'm OK using enum for the StatusCode too.
> 
> Sijie Guo wrote:
>     if you read the conversation about this, my point is that for correct backward compatibility, we should avoid sending unknown error codes back to an old client.

So server should have version specific checks and generates the error codes, isn't it ?. 


- Rakesh


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/17895/#review41130
-----------------------------------------------------------


On April 24, 2014, 7:43 a.m., Sijie Guo wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/17895/
> -----------------------------------------------------------
> 
> (Updated April 24, 2014, 7:43 a.m.)
> 
> 
> Review request for bookkeeper and Ivan Kelly.
> 
> 
> Bugs: BOOKKEEPER-582
>     https://issues.apache.org/jira/browse/BOOKKEEPER-582
> 
> 
> Repository: bookkeeper-git
> 
> 
> Description
> -------
> 
> - introducing protobuf support for bookkeeper
> - for server: introduce packet processor / EnDecoder for different protocol supports
> - for client: change PCBC to use protobuf to send requests
> - misc changes for protobuf support
> 
> (bookie server is able for backward compatibility) 
> 
> 
> Diffs
> -----
> 
>   bookkeeper-server/pom.xml ebc1198 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/bookie/IndexInMemPageMgr.java 56487aa 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/LedgerChecker.java 28e23d6 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/PendingReadOp.java fb36b90 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/processor/RequestProcessor.java 241f369 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieProtoEncoding.java 1154047 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestHandler.java b922a82 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestProcessor.java 8155b22 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookkeeperProtocol.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBase.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBaseV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PerChannelBookieClient.java a10f7d5 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/proto/BookkeeperProtocol.proto PRE-CREATION 
>   bookkeeper-server/src/main/resources/findbugsExclude.xml 97a6156 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/proto/TestProtoVersions.java 5fcc445 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/replication/AuditorPeriodicCheckTest.java 3f8496f 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/BookieClientTest.java bc05229 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/TestBackwardCompat.java 8376b46 
>   compat-deps/bookkeeper-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/hedwig-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/pom.xml f79582d 
>   hedwig-server/pom.xml 06cf01c 
>   hedwig-server/src/test/java/org/apache/hedwig/server/TestBackwardCompat.java 8da109e 
> 
> Diff: https://reviews.apache.org/r/17895/diff/
> 
> 
> Testing
> -------
> 
> unit tests. backward tests.
> 
> 
> Thanks,
> 
> Sijie Guo
> 
>

Re: Review Request 17895: BOOKKEEPER-582: protobuf support for bookkeeper

Posted by Sijie Guo <gu...@gmail.com>.


> On April 23, 2014, 10:22 a.m., Ivan Kelly wrote:
> > bookkeeper-server/src/main/proto/BookkeeperProtocol.proto, line 33
> > <https://reviews.apache.org/r/17895/diff/2/?file=563033#file563033line33>
> >
> >     This should certainly not be an enum. Otherwise we need to bump the protocol version each time we add an error code.
> >     
> >     Imagine the scenario where both server and client are running 4.3.0. Then the server is upgraded with 4.3.1 which a new error EPRINTERONFIRE. It sends this to the client who throws a decode error.
> 
> Sijie Guo wrote:
>     how could being not enum help this? if it is integer, client still has no idea how to interpret, so it is still invalid response from 4.3.0 client. I thought we reached an agreement on enum on the ticket, no?
> 
> Ivan Kelly wrote:
>     So for version and operationtype, enum is ok. These originate at the client, so if the servers are always upgraded at the client, there's no interoperability issues. Status codes originate at the server though, so it is possible for the server to send a statuscode that is unrecognised to a client. The normal way to handle this would be a "else" or "default:" to pass this up to the client as a BKException.UnexpectedConditionException. If it's an enum, this will throw a decode exception in the netty decoder, which is harder to handle.
>     
>     To resolve this on the server side, by checking the version and only sending errors valid for that version, implies two things. Firstly, every error code change will require the version to be bumped and secondly, that there will need to be a list maintained for which errors are valid for each version. This goes against the motivation for using protobuf in the first place.
> 
> Sijie Guo wrote:
>     this is the application level agreement, no? it doesn't matter that u are using a protobuf protocol or using current protocol, or it also doesn't matter that u are using an integer or an enum. in any case, the best way is as you described, you shouldn't send new status code back to an old client, as the new status code is meaningless to the old client.
> 
> Ivan Kelly wrote:
>     but how do you know its an old client? Only by bumping the version number each time you add an error code. In which case you end up with a whole lot of junk like "if (client.version == X) { send A } else if (client.version == Y) { send B } else if (client.version ..." which is exactly what protobuf was designed to avoid (see "A bit of history" on https://developers.google.com/protocol-buffers/docs/overview).
> 
> Sijie Guo wrote:
>     a else or default branch would make the behavior unpredictable as an old client is treating a new status code as some kind of unknown. as you said, you want to treat them as UnexpectedConditionException. But what does UnexpectedConditionException means? doesn't it mean the sever already breaks backward compatibility, since server couldn't satisfy the old client's request.
>     
>     so still, if server wants to be backward compatibility to clients, in any cases, it needs to know what version of protocol that the client is speaking and handle them accordingly, not just let client to do their job in an unexpected way.
>     
>     I don't see any elegant solutions without detecting protocol version. if you have, please describe how not being enum would avoid this.
> 
> Ivan Kelly wrote:
>     the default behaviour for an unknown error code is something we already use today.
>     https://github.com/apache/bookkeeper/blob/trunk/bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PerChannelBookieClient.java#L714
>     
>     The client only needs to know that the request failed. the point of the different error codes is so that the client could take specific recovery steps. the default behaviour is just to pass the error up.
> 
> Sijie Guo wrote:
>     the default behavior was there just for all already known status codes. but it doesn't mean it is correct for any unknown status codes. and when u are saying 'the client only needs to know that the request failed', you are making an assumption that there is only one status code indicating OK, other status code should be taken as failed. but it isn't true. say in an old protocol, we supported range reads, it responded with OK, list of entry response (0 = <data>, 1 = missing, 2 = missing, 3 = <data>). if we are going to improve our protocol to make communication more efficient, we are going to change the protocol to get rid of transferring missing entries: responding with PARTIAL_OK, list of existing entries (0 = <data>, 3 = <data>). 
>     
>     in this case, if server doesn't distinguish the client's protocol, just respond every range reads with PARTIAL_OK, would did break the compatibility with old protocol, as old protocol treats it as failure by default behavior. in order to maintain backward compatibility, server needs to detect the client's protocol and responds accordingly. as what I said, for backward compatibility, a protocol doesn't really help if it involves behavior in application agreement. and a default behavior is not exact right.
>     
>     for me, using protocol. it means that it is easy for us to add new requests type, add new fields in existing requests. besides that, we need to keep the backward compatibility in our level.
> 
> Ivan Kelly wrote:
>     when i say that 'the client only needs to know that the request failed', it means that the client only needs to recognise the statuses which indicate success. for any request, the status codes which indicate success should never change. For a read request or add request, only OK is SUCCESS. For range read,  only PARTIAL_OK and OK are success. But the client will never send a range read request unless it already knows about PARTIAL_OK.
> 
> Sijie Guo wrote:
>     > “But the client will never send a range read request unless it already knows about PARTIAL_OK.” 
>     
>     the example that I made is that the range read introduced with OK, but if it is going to evolved to have PARTIAL_OK. then that will be an problem.
> 
> Ivan Kelly wrote:
>     Partial_ok doesn't make sense if you're using the concept of packet status and operation status (as mentioned below).
> 
> Sijie Guo wrote:
>     well, if u are talking about a specific case (e.g. range read), I might agree with u. but if you read my comments, it is just the case that I explained how the protocol might be evolved. And my point is and always will be for backward compatibility, the server shouldn't send any unknown codes/fields back to clients that speaks old protocol, this is part of application-level agreement, no matter using enum or integer.
> 
> Rakesh R wrote:
>     Using enum is more readable and would be good for newcomers too. Assume a case where we are introducing new EC for an existing request type at the side server side, EC#NEW_ERR_CODE in 4.3.1 and client is old one 4.3.0. Ideally in this case, bk client should say its unknown code.
>     
>     Does this create any parsing issues at the protobuf ?. If not, I'm OK using enum for the StatusCode too.
> 
> Sijie Guo wrote:
>     if you read the conversation about this, my point is that for correct backward compatibility, we should avoid sending unknown error codes back to an old client.
> 
> Rakesh R wrote:
>     So server should have version specific checks and generates the error codes, isn't it ?.
> 
> Sijie Guo wrote:
>     yes. exact as what I pointed. sending responses matching exact version of protocol, isn't that exactly for application level backward compatible? why this would be the concern?
> 
> Rakesh R wrote:
>     There is no big concern here. I'm trying to understand the current approach and the future path to avoid any compatibility issues later.
> 
> Sijie Guo wrote:
>     for backward compatibility, it is comprised of wire compatibility and application-semantic compatibility. using protobuf, we could easily achieve wire compatibility by adding new optional fields. for application-semantic, the server needs to detect what version of the client is talking, and send correct version of responses according to its version. the version field in the request/response structure helps achieving this.
> 
> Rakesh R wrote:
>     Maintaining version list has its own complexities, but again it depends on the client side requirements. As I know protobuf parser would not get decode exceptions if any unknown enum code comes from server, instead this will return a null value. If this is the behavior of protobuf, then today its not a blocker for this patch. Because in your patch, you have already handled unknown error code in PerChannelBookieClient#statusCodeToExceptionCode() and treats this code as an op failure.
> 
> Sijie Guo wrote:
>     version list is more for application level semantic backward compatibility. a clear specific version for backward compatibility would be more clear than any implicit solution. although it might introduce code, it is clear for maintenance.
> 
> Rakesh R wrote:
>     OK. My point is, since we have already unknown error code handling at the client side, we can discuss this case alone later. Today its not a concern for this patch, but we can atleast remember this point for future discussion :-)
>     
>     +        Integer rcToRet = statusCodeToExceptionCode(status);
>     +        if (null == rcToRet) {
>     +            rcToRet = BKException.Code.WriteException;
>     
>     +        Integer rcToRet = statusCodeToExceptionCode(status);
>     +        if (null == rcToRet) {
>     +            rcToRet = BKException.Code.ReadException;

what else I need to address for this? or does it mean enum works for u?


- Sijie


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/17895/#review41130
-----------------------------------------------------------


On April 24, 2014, 7:43 a.m., Sijie Guo wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/17895/
> -----------------------------------------------------------
> 
> (Updated April 24, 2014, 7:43 a.m.)
> 
> 
> Review request for bookkeeper and Ivan Kelly.
> 
> 
> Bugs: BOOKKEEPER-582
>     https://issues.apache.org/jira/browse/BOOKKEEPER-582
> 
> 
> Repository: bookkeeper-git
> 
> 
> Description
> -------
> 
> - introducing protobuf support for bookkeeper
> - for server: introduce packet processor / EnDecoder for different protocol supports
> - for client: change PCBC to use protobuf to send requests
> - misc changes for protobuf support
> 
> (bookie server is able for backward compatibility) 
> 
> 
> Diffs
> -----
> 
>   bookkeeper-server/pom.xml ebc1198 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/bookie/IndexInMemPageMgr.java 56487aa 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/LedgerChecker.java 28e23d6 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/PendingReadOp.java fb36b90 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/processor/RequestProcessor.java 241f369 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieProtoEncoding.java 1154047 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestHandler.java b922a82 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestProcessor.java 8155b22 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookkeeperProtocol.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBase.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBaseV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PerChannelBookieClient.java a10f7d5 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/proto/BookkeeperProtocol.proto PRE-CREATION 
>   bookkeeper-server/src/main/resources/findbugsExclude.xml 97a6156 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/proto/TestProtoVersions.java 5fcc445 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/replication/AuditorPeriodicCheckTest.java 3f8496f 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/BookieClientTest.java bc05229 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/TestBackwardCompat.java 8376b46 
>   compat-deps/bookkeeper-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/hedwig-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/pom.xml f79582d 
>   hedwig-server/pom.xml 06cf01c 
>   hedwig-server/src/test/java/org/apache/hedwig/server/TestBackwardCompat.java 8da109e 
> 
> Diff: https://reviews.apache.org/r/17895/diff/
> 
> 
> Testing
> -------
> 
> unit tests. backward tests.
> 
> 
> Thanks,
> 
> Sijie Guo
> 
>

Re: Review Request 17895: BOOKKEEPER-582: protobuf support for bookkeeper

Posted by Sijie Guo <gu...@gmail.com>.


> On April 23, 2014, 10:22 a.m., Ivan Kelly wrote:
> >

ok. let me step back. how bad is the current protocol? if no, why we keep arguing on this? as those changes will break our system, then I don't see the value of contributing our patches back to the community.


- Sijie


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/17895/#review41130
-----------------------------------------------------------


On April 24, 2014, 7:43 a.m., Sijie Guo wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/17895/
> -----------------------------------------------------------
> 
> (Updated April 24, 2014, 7:43 a.m.)
> 
> 
> Review request for bookkeeper and Ivan Kelly.
> 
> 
> Bugs: BOOKKEEPER-582
>     https://issues.apache.org/jira/browse/BOOKKEEPER-582
> 
> 
> Repository: bookkeeper-git
> 
> 
> Description
> -------
> 
> - introducing protobuf support for bookkeeper
> - for server: introduce packet processor / EnDecoder for different protocol supports
> - for client: change PCBC to use protobuf to send requests
> - misc changes for protobuf support
> 
> (bookie server is able for backward compatibility) 
> 
> 
> Diffs
> -----
> 
>   bookkeeper-server/pom.xml ebc1198 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/bookie/IndexInMemPageMgr.java 56487aa 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/LedgerChecker.java 28e23d6 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/PendingReadOp.java fb36b90 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/processor/RequestProcessor.java 241f369 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieProtoEncoding.java 1154047 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestHandler.java b922a82 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestProcessor.java 8155b22 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookkeeperProtocol.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBase.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBaseV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PerChannelBookieClient.java a10f7d5 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/proto/BookkeeperProtocol.proto PRE-CREATION 
>   bookkeeper-server/src/main/resources/findbugsExclude.xml 97a6156 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/proto/TestProtoVersions.java 5fcc445 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/replication/AuditorPeriodicCheckTest.java 3f8496f 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/BookieClientTest.java bc05229 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/TestBackwardCompat.java 8376b46 
>   compat-deps/bookkeeper-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/hedwig-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/pom.xml f79582d 
>   hedwig-server/pom.xml 06cf01c 
>   hedwig-server/src/test/java/org/apache/hedwig/server/TestBackwardCompat.java 8da109e 
> 
> Diff: https://reviews.apache.org/r/17895/diff/
> 
> 
> Testing
> -------
> 
> unit tests. backward tests.
> 
> 
> Thanks,
> 
> Sijie Guo
> 
>

Re: Review Request 17895: BOOKKEEPER-582: protobuf support for bookkeeper

Posted by Sijie Guo <gu...@gmail.com>.


> On April 23, 2014, 10:22 a.m., Ivan Kelly wrote:
> > bookkeeper-server/src/main/proto/BookkeeperProtocol.proto, line 104
> > <https://reviews.apache.org/r/17895/diff/2/?file=563033#file563033line104>
> >
> >     You're sending StatusCode twice, every time. Firstly, shouldn't be an enum as stated above. Secondly, shouldn't be required.
> 
> Sijie Guo wrote:
>     > enum
>     
>     as the comments above.
>     
>     > status code twice.
>     
>     the status code for ReadResponse/AddResponse is for individual responses. if we are going to support kind of batch reads, the status code of Response means either the whole batch succeed or not while the individual read responses might have different status codes (e.g OK or NotExists). That is why it exists two places.
>     
>     > required
>     
>     as the comments above
> 
> Ivan Kelly wrote:
>     Per request makes sense. However, in that case, can't you just remove the per packet status?
> 
> Sijie Guo wrote:
>     Nope. the packet status indicates whether the packet succeed or not. say if it is batch read, if the total batch read failed, it would set the whole packet status to be failed and there would be no individual responses in the packet since the whole batch failed.
> 
> Ivan Kelly wrote:
>     Then it should have a different name. Like entryStatus & packetStatus. But then you also have a consistency problem. What is packetStatus is OK, but one entryStatus is an error? Will there be a SOME_OK error? In what scenario would a whole read batch fail?

if ledger isn't exists, then a packet status with NoSuchLedgerExists is returned. if ledger exists, but some entries are missing, so ok is returned for the packet, but NoSuchEntry would be returned for the missing entries.


> On April 23, 2014, 10:22 a.m., Ivan Kelly wrote:
> > bookkeeper-server/src/main/proto/BookkeeperProtocol.proto, line 80
> > <https://reviews.apache.org/r/17895/diff/2/?file=563033#file563033line80>
> >
> >     This would be better served with a boolean. protobuf will keep it compact.
> 
> Sijie Guo wrote:
>     being Flag will make it easier to add other flags in future.
> 
> Ivan Kelly wrote:
>     No it doesn't. Lets say you do add another flag in the future. How do you specify that it's both a FENCE_LEDGER and NEW_FLAG? You need the field to be repeated, and then you need code to loop through the flags. Compared to msg.isFenceLedger(), this seems much more cumbersome.
> 
> Sijie Guo wrote:
>     I don't say this field is bits-set-like of flags. as the long poll changes we mentioned, we are going to add a new flag 'ENTRY_PIGGYBACK' for read. so a read request is either a normal read (without Flag), a fence read (flag = FENCE_LEDGER) or a piggyback read (flag = ENTRY_PIGGYBACK). Being repeated will be kind of complicated, as you need to loop all possible permutation.
> 
> Ivan Kelly wrote:
>     This is ugly and shortsighted. There may well be a case in the future where two flags need to be specified. What do we do then? Add a flags2 field?

why this couldn't be a 3rd flag? FENCE_LEDGER_AND_PIGGYBACK?

in your repeated way, let's say you have n flags, you would have n! ways to combine them. it is hard to figure out what kind of combination works for what situation. as some of your flags are exclusive with others. so renaming the combination specifically would make it clear.


> On April 23, 2014, 10:22 a.m., Ivan Kelly wrote:
> > bookkeeper-server/src/main/proto/BookkeeperProtocol.proto, line 65
> > <https://reviews.apache.org/r/17895/diff/2/?file=563033#file563033line65>
> >
> >     Comment 1.
> >     OperationType is redundant. The server can do #hasReadRequest and #hasAddRequest to check the request to check the type. We shouldn't send redundant data over the wire where possible.
> >     
> >     Comment 2.
> >     it better to make the absolute minimum to be required. Required is forever, and these may not be.
> >     
> >     https://developers.google.com/protocol-buffers/docs/proto
> >
> 
> Sijie Guo wrote:
>     > comment 1.
>     
>     OperationType will make request more clear and specify and less if...else branches. And OperationType is used for PCBC to unify all requests handling. so we don't need to have individual maps to maintain requests each time we added a new type of requests.
>     
>     > comment 2.
>     
>     if reply to comment 1 works for u, I don't see any reason why operation would not be a required.
> 
> Ivan Kelly wrote:
>     Ok. I can live with it, though I still think it's a little cumbersome. Regarding requiredness, I still think it should be optional. All fields should be optional by default to give you as much freedom to evolve the protocol in the future as possible. Especially something, which is not 100% essential to the protocol, like this field.
> 
> Sijie Guo wrote:
>     for those fields that already exist in the origin protocol, I don't see we are going to remove them. that's why we put it as required.
> 
> Ivan Kelly wrote:
>     We shouldnt prelude the possibility though. What problem could making them optional cause?

what does an response w/o OperationType mean? How PCBC would handle this? as I said, OperationType is somehow guiding us to dispatch the request and response. so it is required.


> On April 23, 2014, 10:22 a.m., Ivan Kelly wrote:
> > bookkeeper-server/src/main/proto/BookkeeperProtocol.proto, line 33
> > <https://reviews.apache.org/r/17895/diff/2/?file=563033#file563033line33>
> >
> >     This should certainly not be an enum. Otherwise we need to bump the protocol version each time we add an error code.
> >     
> >     Imagine the scenario where both server and client are running 4.3.0. Then the server is upgraded with 4.3.1 which a new error EPRINTERONFIRE. It sends this to the client who throws a decode error.
> 
> Sijie Guo wrote:
>     how could being not enum help this? if it is integer, client still has no idea how to interpret, so it is still invalid response from 4.3.0 client. I thought we reached an agreement on enum on the ticket, no?
> 
> Ivan Kelly wrote:
>     So for version and operationtype, enum is ok. These originate at the client, so if the servers are always upgraded at the client, there's no interoperability issues. Status codes originate at the server though, so it is possible for the server to send a statuscode that is unrecognised to a client. The normal way to handle this would be a "else" or "default:" to pass this up to the client as a BKException.UnexpectedConditionException. If it's an enum, this will throw a decode exception in the netty decoder, which is harder to handle.
>     
>     To resolve this on the server side, by checking the version and only sending errors valid for that version, implies two things. Firstly, every error code change will require the version to be bumped and secondly, that there will need to be a list maintained for which errors are valid for each version. This goes against the motivation for using protobuf in the first place.
> 
> Sijie Guo wrote:
>     this is the application level agreement, no? it doesn't matter that u are using a protobuf protocol or using current protocol, or it also doesn't matter that u are using an integer or an enum. in any case, the best way is as you described, you shouldn't send new status code back to an old client, as the new status code is meaningless to the old client.
> 
> Ivan Kelly wrote:
>     but how do you know its an old client? Only by bumping the version number each time you add an error code. In which case you end up with a whole lot of junk like "if (client.version == X) { send A } else if (client.version == Y) { send B } else if (client.version ..." which is exactly what protobuf was designed to avoid (see "A bit of history" on https://developers.google.com/protocol-buffers/docs/overview).

a else or default branch would make the behavior unpredictable as an old client is treating a new status code as some kind of unknown. as you said, you want to treat them as UnexpectedConditionException. But what does UnexpectedConditionException means? doesn't it mean the sever already breaks backward compatibility, since server couldn't satisfy the old client's request.

so still, if server wants to be backward compatibility to clients, in any cases, it needs to know what version of protocol that the client is speaking and handle them accordingly, not just let client to do their job in an unexpected way.

I don't see any elegant solutions without detecting protocol version. if you have, please describe how not being enum would avoid this. 


- Sijie


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/17895/#review41130
-----------------------------------------------------------


On April 24, 2014, 7:43 a.m., Sijie Guo wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/17895/
> -----------------------------------------------------------
> 
> (Updated April 24, 2014, 7:43 a.m.)
> 
> 
> Review request for bookkeeper and Ivan Kelly.
> 
> 
> Bugs: BOOKKEEPER-582
>     https://issues.apache.org/jira/browse/BOOKKEEPER-582
> 
> 
> Repository: bookkeeper-git
> 
> 
> Description
> -------
> 
> - introducing protobuf support for bookkeeper
> - for server: introduce packet processor / EnDecoder for different protocol supports
> - for client: change PCBC to use protobuf to send requests
> - misc changes for protobuf support
> 
> (bookie server is able for backward compatibility) 
> 
> 
> Diffs
> -----
> 
>   bookkeeper-server/pom.xml ebc1198 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/bookie/IndexInMemPageMgr.java 56487aa 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/LedgerChecker.java 28e23d6 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/PendingReadOp.java fb36b90 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/processor/RequestProcessor.java 241f369 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieProtoEncoding.java 1154047 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestHandler.java b922a82 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestProcessor.java 8155b22 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookkeeperProtocol.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBase.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBaseV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PerChannelBookieClient.java a10f7d5 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/proto/BookkeeperProtocol.proto PRE-CREATION 
>   bookkeeper-server/src/main/resources/findbugsExclude.xml 97a6156 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/proto/TestProtoVersions.java 5fcc445 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/replication/AuditorPeriodicCheckTest.java 3f8496f 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/BookieClientTest.java bc05229 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/TestBackwardCompat.java 8376b46 
>   compat-deps/bookkeeper-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/hedwig-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/pom.xml f79582d 
>   hedwig-server/pom.xml 06cf01c 
>   hedwig-server/src/test/java/org/apache/hedwig/server/TestBackwardCompat.java 8da109e 
> 
> Diff: https://reviews.apache.org/r/17895/diff/
> 
> 
> Testing
> -------
> 
> unit tests. backward tests.
> 
> 
> Thanks,
> 
> Sijie Guo
> 
>

Re: Review Request 17895: BOOKKEEPER-582: protobuf support for bookkeeper

Posted by Sijie Guo <gu...@gmail.com>.


> On April 23, 2014, 10:22 a.m., Ivan Kelly wrote:
> >
> 
> Sijie Guo wrote:
>     ok. let me step back. how bad is the current protocol? if no, why we keep arguing on this? as those changes will break our system, then I don't see the value of contributing our patches back to the community.
> 
> Ivan Kelly wrote:
>     For me, the motivating change was auth. The initial drop I did for auth[1] was based in PB to allow for auth providers to include their own extensions with PB and not have to deal with parsing. This was mixing old parsing and PB though, so I held off the change until PB went in, so that we wouldnt have two parsing mechanisms being actively developed.
>     
>     For me, this motivation is still valid. Having two decoding mechanisms is ugly and hacky. With the plan to add batch reads,it also makes sense to be easily able to add messages.
>     
>     Another motivation is to reduce the variation between the branches. We currently have 3 branchs, the apache branch, the twitter branch and the yahoo branch (perhaps huawei also have a branch). These will unlikely ever be 100% identical, but I had hoped that we could keep the difference to a minimum to allow for us to be able to benefit from each others changes.
>     
>     That said, changes from all sides need to go through the full review process before going in. Both companies have different production usecases, roadmaps, and rollout mechanisms, so assumptions may not hold across organisations.
>     
>     To bring it back to the current patch, and your initial question, the current protocol isn't terrible. The code for it is a hell of a lot cleaner than it was 2 years ago. However, it's cumbersome to add anything to the protocol, mostly because of decisions taken early on, (such as the difference in position of ledgerid and entryid in read and add requests). I was hoping we could avoid locking ourselves into something like this again. 
>     
>     [1] https://github.com/ivankelly/bookkeeper/commits/BookKeeperAuth

ok. replies on your individual concerns. 


> On April 23, 2014, 10:22 a.m., Ivan Kelly wrote:
> > bookkeeper-server/src/main/proto/BookkeeperProtocol.proto, line 33
> > <https://reviews.apache.org/r/17895/diff/2/?file=563033#file563033line33>
> >
> >     This should certainly not be an enum. Otherwise we need to bump the protocol version each time we add an error code.
> >     
> >     Imagine the scenario where both server and client are running 4.3.0. Then the server is upgraded with 4.3.1 which a new error EPRINTERONFIRE. It sends this to the client who throws a decode error.
> 
> Sijie Guo wrote:
>     how could being not enum help this? if it is integer, client still has no idea how to interpret, so it is still invalid response from 4.3.0 client. I thought we reached an agreement on enum on the ticket, no?
> 
> Ivan Kelly wrote:
>     So for version and operationtype, enum is ok. These originate at the client, so if the servers are always upgraded at the client, there's no interoperability issues. Status codes originate at the server though, so it is possible for the server to send a statuscode that is unrecognised to a client. The normal way to handle this would be a "else" or "default:" to pass this up to the client as a BKException.UnexpectedConditionException. If it's an enum, this will throw a decode exception in the netty decoder, which is harder to handle.
>     
>     To resolve this on the server side, by checking the version and only sending errors valid for that version, implies two things. Firstly, every error code change will require the version to be bumped and secondly, that there will need to be a list maintained for which errors are valid for each version. This goes against the motivation for using protobuf in the first place.
> 
> Sijie Guo wrote:
>     this is the application level agreement, no? it doesn't matter that u are using a protobuf protocol or using current protocol, or it also doesn't matter that u are using an integer or an enum. in any case, the best way is as you described, you shouldn't send new status code back to an old client, as the new status code is meaningless to the old client.
> 
> Ivan Kelly wrote:
>     but how do you know its an old client? Only by bumping the version number each time you add an error code. In which case you end up with a whole lot of junk like "if (client.version == X) { send A } else if (client.version == Y) { send B } else if (client.version ..." which is exactly what protobuf was designed to avoid (see "A bit of history" on https://developers.google.com/protocol-buffers/docs/overview).
> 
> Sijie Guo wrote:
>     a else or default branch would make the behavior unpredictable as an old client is treating a new status code as some kind of unknown. as you said, you want to treat them as UnexpectedConditionException. But what does UnexpectedConditionException means? doesn't it mean the sever already breaks backward compatibility, since server couldn't satisfy the old client's request.
>     
>     so still, if server wants to be backward compatibility to clients, in any cases, it needs to know what version of protocol that the client is speaking and handle them accordingly, not just let client to do their job in an unexpected way.
>     
>     I don't see any elegant solutions without detecting protocol version. if you have, please describe how not being enum would avoid this.
> 
> Ivan Kelly wrote:
>     the default behaviour for an unknown error code is something we already use today.
>     https://github.com/apache/bookkeeper/blob/trunk/bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PerChannelBookieClient.java#L714
>     
>     The client only needs to know that the request failed. the point of the different error codes is so that the client could take specific recovery steps. the default behaviour is just to pass the error up.

the default behavior was there just for all already known status codes. but it doesn't mean it is correct for any unknown status codes. and when u are saying 'the client only needs to know that the request failed', you are making an assumption that there is only one status code indicating OK, other status code should be taken as failed. but it isn't true. say in an old protocol, we supported range reads, it responded with OK, list of entry response (0 = <data>, 1 = missing, 2 = missing, 3 = <data>). if we are going to improve our protocol to make communication more efficient, we are going to change the protocol to get rid of transferring missing entries: responding with PARTIAL_OK, list of existing entries (0 = <data>, 3 = <data>). 

in this case, if server doesn't distinguish the client's protocol, just respond every range reads with PARTIAL_OK, would did break the compatibility with old protocol, as old protocol treats it as failure by default behavior. in order to maintain backward compatibility, server needs to detect the client's protocol and responds accordingly. as what I said, for backward compatibility, a protocol doesn't really help if it involves behavior in application agreement. and a default behavior is not exact right.

for me, using protocol. it means that it is easy for us to add new requests type, add new fields in existing requests. besides that, we need to keep the backward compatibility in our level. 


> On April 23, 2014, 10:22 a.m., Ivan Kelly wrote:
> > bookkeeper-server/src/main/proto/BookkeeperProtocol.proto, line 65
> > <https://reviews.apache.org/r/17895/diff/2/?file=563033#file563033line65>
> >
> >     Comment 1.
> >     OperationType is redundant. The server can do #hasReadRequest and #hasAddRequest to check the request to check the type. We shouldn't send redundant data over the wire where possible.
> >     
> >     Comment 2.
> >     it better to make the absolute minimum to be required. Required is forever, and these may not be.
> >     
> >     https://developers.google.com/protocol-buffers/docs/proto
> >
> 
> Sijie Guo wrote:
>     > comment 1.
>     
>     OperationType will make request more clear and specify and less if...else branches. And OperationType is used for PCBC to unify all requests handling. so we don't need to have individual maps to maintain requests each time we added a new type of requests.
>     
>     > comment 2.
>     
>     if reply to comment 1 works for u, I don't see any reason why operation would not be a required.
> 
> Ivan Kelly wrote:
>     Ok. I can live with it, though I still think it's a little cumbersome. Regarding requiredness, I still think it should be optional. All fields should be optional by default to give you as much freedom to evolve the protocol in the future as possible. Especially something, which is not 100% essential to the protocol, like this field.
> 
> Sijie Guo wrote:
>     for those fields that already exist in the origin protocol, I don't see we are going to remove them. that's why we put it as required.
> 
> Ivan Kelly wrote:
>     We shouldnt prelude the possibility though. What problem could making them optional cause?
> 
> Sijie Guo wrote:
>     what does an response w/o OperationType mean? How PCBC would handle this? as I said, OperationType is somehow guiding us to dispatch the request and response. so it is required.
> 
> Ivan Kelly wrote:
>     the operation type can be inferred from the contents as i said already. So OperationType itself isnt actually required, so we should lock it in at this point.

say you have A, B, C types of requests, you have resp_A, resp_B, resp_C optional fields in response. if using OperationType, you explicitly know what response that the request is for. it reduce the branches that u need to check if the response is valid or not: for example, for response A, it just need to check if resp_A exists or not. if not, it is an invalid response for A. you don't need to touch resp_B and resp_C.

if OperationType is not used, you need to write lots of if..else branches to identify what's the response for. e.g. hasResp_A & !hasResp_B & !hasResp_C is for request type A. even worser, if you are adding new request type, you need to change all the if...else branches. 


> On April 23, 2014, 10:22 a.m., Ivan Kelly wrote:
> > bookkeeper-server/src/main/proto/BookkeeperProtocol.proto, line 80
> > <https://reviews.apache.org/r/17895/diff/2/?file=563033#file563033line80>
> >
> >     This would be better served with a boolean. protobuf will keep it compact.
> 
> Sijie Guo wrote:
>     being Flag will make it easier to add other flags in future.
> 
> Ivan Kelly wrote:
>     No it doesn't. Lets say you do add another flag in the future. How do you specify that it's both a FENCE_LEDGER and NEW_FLAG? You need the field to be repeated, and then you need code to loop through the flags. Compared to msg.isFenceLedger(), this seems much more cumbersome.
> 
> Sijie Guo wrote:
>     I don't say this field is bits-set-like of flags. as the long poll changes we mentioned, we are going to add a new flag 'ENTRY_PIGGYBACK' for read. so a read request is either a normal read (without Flag), a fence read (flag = FENCE_LEDGER) or a piggyback read (flag = ENTRY_PIGGYBACK). Being repeated will be kind of complicated, as you need to loop all possible permutation.
> 
> Ivan Kelly wrote:
>     This is ugly and shortsighted. There may well be a case in the future where two flags need to be specified. What do we do then? Add a flags2 field?
> 
> Sijie Guo wrote:
>     why this couldn't be a 3rd flag? FENCE_LEDGER_AND_PIGGYBACK?
>     
>     in your repeated way, let's say you have n flags, you would have n! ways to combine them. it is hard to figure out what kind of combination works for what situation. as some of your flags are exclusive with others. so renaming the combination specifically would make it clear.
> 
> Ivan Kelly wrote:
>     as you say, with n flags specified, there are n! combinations. so if another flag as added, you will have to add n values to the enum to cover the different combinations. whether the flags are exclusive is for the application to decide. it shouldnt be implicit in the protocol encoding.

same explanation for OperationType is applying here. if n flags mostly are used individually, an explicit way will just need to deal with around n possibilities. but you need to write lots of if..else branches for inferring in an implicit way.


- Sijie


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/17895/#review41130
-----------------------------------------------------------


On April 24, 2014, 7:43 a.m., Sijie Guo wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/17895/
> -----------------------------------------------------------
> 
> (Updated April 24, 2014, 7:43 a.m.)
> 
> 
> Review request for bookkeeper and Ivan Kelly.
> 
> 
> Bugs: BOOKKEEPER-582
>     https://issues.apache.org/jira/browse/BOOKKEEPER-582
> 
> 
> Repository: bookkeeper-git
> 
> 
> Description
> -------
> 
> - introducing protobuf support for bookkeeper
> - for server: introduce packet processor / EnDecoder for different protocol supports
> - for client: change PCBC to use protobuf to send requests
> - misc changes for protobuf support
> 
> (bookie server is able for backward compatibility) 
> 
> 
> Diffs
> -----
> 
>   bookkeeper-server/pom.xml ebc1198 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/bookie/IndexInMemPageMgr.java 56487aa 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/LedgerChecker.java 28e23d6 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/PendingReadOp.java fb36b90 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/processor/RequestProcessor.java 241f369 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieProtoEncoding.java 1154047 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestHandler.java b922a82 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestProcessor.java 8155b22 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookkeeperProtocol.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBase.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBaseV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PerChannelBookieClient.java a10f7d5 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/proto/BookkeeperProtocol.proto PRE-CREATION 
>   bookkeeper-server/src/main/resources/findbugsExclude.xml 97a6156 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/proto/TestProtoVersions.java 5fcc445 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/replication/AuditorPeriodicCheckTest.java 3f8496f 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/BookieClientTest.java bc05229 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/TestBackwardCompat.java 8376b46 
>   compat-deps/bookkeeper-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/hedwig-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/pom.xml f79582d 
>   hedwig-server/pom.xml 06cf01c 
>   hedwig-server/src/test/java/org/apache/hedwig/server/TestBackwardCompat.java 8da109e 
> 
> Diff: https://reviews.apache.org/r/17895/diff/
> 
> 
> Testing
> -------
> 
> unit tests. backward tests.
> 
> 
> Thanks,
> 
> Sijie Guo
> 
>

Re: Review Request 17895: BOOKKEEPER-582: protobuf support for bookkeeper

Posted by Sijie Guo <gu...@gmail.com>.


> On April 23, 2014, 10:22 a.m., Ivan Kelly wrote:
> > bookkeeper-server/src/main/proto/BookkeeperProtocol.proto, line 33
> > <https://reviews.apache.org/r/17895/diff/2/?file=563033#file563033line33>
> >
> >     This should certainly not be an enum. Otherwise we need to bump the protocol version each time we add an error code.
> >     
> >     Imagine the scenario where both server and client are running 4.3.0. Then the server is upgraded with 4.3.1 which a new error EPRINTERONFIRE. It sends this to the client who throws a decode error.
> 
> Sijie Guo wrote:
>     how could being not enum help this? if it is integer, client still has no idea how to interpret, so it is still invalid response from 4.3.0 client. I thought we reached an agreement on enum on the ticket, no?
> 
> Ivan Kelly wrote:
>     So for version and operationtype, enum is ok. These originate at the client, so if the servers are always upgraded at the client, there's no interoperability issues. Status codes originate at the server though, so it is possible for the server to send a statuscode that is unrecognised to a client. The normal way to handle this would be a "else" or "default:" to pass this up to the client as a BKException.UnexpectedConditionException. If it's an enum, this will throw a decode exception in the netty decoder, which is harder to handle.
>     
>     To resolve this on the server side, by checking the version and only sending errors valid for that version, implies two things. Firstly, every error code change will require the version to be bumped and secondly, that there will need to be a list maintained for which errors are valid for each version. This goes against the motivation for using protobuf in the first place.

this is the application level agreement, no? it doesn't matter that u are using a protobuf protocol or using current protocol, or it also doesn't matter that u are using an integer or an enum. in any case, the best way is as you described, you shouldn't send new status code back to an old client, as the new status code is meaningless to the old client. 


> On April 23, 2014, 10:22 a.m., Ivan Kelly wrote:
> > bookkeeper-server/src/main/proto/BookkeeperProtocol.proto, line 65
> > <https://reviews.apache.org/r/17895/diff/2/?file=563033#file563033line65>
> >
> >     Comment 1.
> >     OperationType is redundant. The server can do #hasReadRequest and #hasAddRequest to check the request to check the type. We shouldn't send redundant data over the wire where possible.
> >     
> >     Comment 2.
> >     it better to make the absolute minimum to be required. Required is forever, and these may not be.
> >     
> >     https://developers.google.com/protocol-buffers/docs/proto
> >
> 
> Sijie Guo wrote:
>     > comment 1.
>     
>     OperationType will make request more clear and specify and less if...else branches. And OperationType is used for PCBC to unify all requests handling. so we don't need to have individual maps to maintain requests each time we added a new type of requests.
>     
>     > comment 2.
>     
>     if reply to comment 1 works for u, I don't see any reason why operation would not be a required.
> 
> Ivan Kelly wrote:
>     Ok. I can live with it, though I still think it's a little cumbersome. Regarding requiredness, I still think it should be optional. All fields should be optional by default to give you as much freedom to evolve the protocol in the future as possible. Especially something, which is not 100% essential to the protocol, like this field.

for those fields that already exist in the origin protocol, I don't see we are going to remove them. that's why we put it as required. 


> On April 23, 2014, 10:22 a.m., Ivan Kelly wrote:
> > bookkeeper-server/src/main/proto/BookkeeperProtocol.proto, line 80
> > <https://reviews.apache.org/r/17895/diff/2/?file=563033#file563033line80>
> >
> >     This would be better served with a boolean. protobuf will keep it compact.
> 
> Sijie Guo wrote:
>     being Flag will make it easier to add other flags in future.
> 
> Ivan Kelly wrote:
>     No it doesn't. Lets say you do add another flag in the future. How do you specify that it's both a FENCE_LEDGER and NEW_FLAG? You need the field to be repeated, and then you need code to loop through the flags. Compared to msg.isFenceLedger(), this seems much more cumbersome.

I don't say this field is bits-set-like of flags. as the long poll changes we mentioned, we are going to add a new flag 'ENTRY_PIGGYBACK' for read. so a read request is either a normal read (without Flag), a fence read (flag = FENCE_LEDGER) or a piggyback read (flag = ENTRY_PIGGYBACK). Being repeated will be kind of complicated, as you need to loop all possible permutation.


> On April 23, 2014, 10:22 a.m., Ivan Kelly wrote:
> > bookkeeper-server/src/main/proto/BookkeeperProtocol.proto, line 104
> > <https://reviews.apache.org/r/17895/diff/2/?file=563033#file563033line104>
> >
> >     You're sending StatusCode twice, every time. Firstly, shouldn't be an enum as stated above. Secondly, shouldn't be required.
> 
> Sijie Guo wrote:
>     > enum
>     
>     as the comments above.
>     
>     > status code twice.
>     
>     the status code for ReadResponse/AddResponse is for individual responses. if we are going to support kind of batch reads, the status code of Response means either the whole batch succeed or not while the individual read responses might have different status codes (e.g OK or NotExists). That is why it exists two places.
>     
>     > required
>     
>     as the comments above
> 
> Ivan Kelly wrote:
>     Per request makes sense. However, in that case, can't you just remove the per packet status?

Nope. the packet status indicates whether the packet succeed or not. say if it is batch read, if the total batch read failed, it would set the whole packet status to be failed and there would be no individual responses in the packet since the whole batch failed. 


- Sijie


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/17895/#review41130
-----------------------------------------------------------


On April 24, 2014, 7:43 a.m., Sijie Guo wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/17895/
> -----------------------------------------------------------
> 
> (Updated April 24, 2014, 7:43 a.m.)
> 
> 
> Review request for bookkeeper and Ivan Kelly.
> 
> 
> Bugs: BOOKKEEPER-582
>     https://issues.apache.org/jira/browse/BOOKKEEPER-582
> 
> 
> Repository: bookkeeper-git
> 
> 
> Description
> -------
> 
> - introducing protobuf support for bookkeeper
> - for server: introduce packet processor / EnDecoder for different protocol supports
> - for client: change PCBC to use protobuf to send requests
> - misc changes for protobuf support
> 
> (bookie server is able for backward compatibility) 
> 
> 
> Diffs
> -----
> 
>   bookkeeper-server/pom.xml ebc1198 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/bookie/IndexInMemPageMgr.java 56487aa 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/LedgerChecker.java 28e23d6 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/PendingReadOp.java fb36b90 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/processor/RequestProcessor.java 241f369 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieProtoEncoding.java 1154047 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestHandler.java b922a82 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestProcessor.java 8155b22 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookkeeperProtocol.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBase.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBaseV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PerChannelBookieClient.java a10f7d5 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/proto/BookkeeperProtocol.proto PRE-CREATION 
>   bookkeeper-server/src/main/resources/findbugsExclude.xml 97a6156 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/proto/TestProtoVersions.java 5fcc445 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/replication/AuditorPeriodicCheckTest.java 3f8496f 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/BookieClientTest.java bc05229 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/TestBackwardCompat.java 8376b46 
>   compat-deps/bookkeeper-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/hedwig-server-compat-4.2.0/pom.xml PRE-CREATION 
>   compat-deps/pom.xml f79582d 
>   hedwig-server/pom.xml 06cf01c 
>   hedwig-server/src/test/java/org/apache/hedwig/server/TestBackwardCompat.java 8da109e 
> 
> Diff: https://reviews.apache.org/r/17895/diff/
> 
> 
> Testing
> -------
> 
> unit tests. backward tests.
> 
> 
> Thanks,
> 
> Sijie Guo
> 
>

Re: Review Request 17895: BOOKKEEPER-582: protobuf support for bookkeeper

Posted by Ivan Kelly <iv...@apache.org>.

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/17895/#review41130
-----------------------------------------------------------



bookkeeper-server/src/main/java/org/apache/bookkeeper/client/LedgerChecker.java
<https://reviews.apache.org/r/17895/#comment74543>

    This change seems unrelated. I don't mind it going in, but could you give some background as to why it's here?



bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestProcessor.java
<https://reviews.apache.org/r/17895/#comment74542>

    typo



bookkeeper-server/src/main/proto/BookkeeperProtocol.proto
<https://reviews.apache.org/r/17895/#comment74544>

    This should certainly not be an enum. Otherwise we need to bump the protocol version each time we add an error code.
    
    Imagine the scenario where both server and client are running 4.3.0. Then the server is upgraded with 4.3.1 which a new error EPRINTERONFIRE. It sends this to the client who throws a decode error.



bookkeeper-server/src/main/proto/BookkeeperProtocol.proto
<https://reviews.apache.org/r/17895/#comment74547>

    Comment 1.
    OperationType is redundant. The server can do #hasReadRequest and #hasAddRequest to check the request to check the type. We shouldn't send redundant data over the wire where possible.
    
    Comment 2.
    it better to make the absolute minimum to be required. Required is forever, and these may not be.
    
    https://developers.google.com/protocol-buffers/docs/proto
    



bookkeeper-server/src/main/proto/BookkeeperProtocol.proto
<https://reviews.apache.org/r/17895/#comment74545>

    This would be better served with a boolean. protobuf will keep it compact.



bookkeeper-server/src/main/proto/BookkeeperProtocol.proto
<https://reviews.apache.org/r/17895/#comment74546>

    same as fenced, better as boolean



bookkeeper-server/src/main/proto/BookkeeperProtocol.proto
<https://reviews.apache.org/r/17895/#comment74548>

    You're sending StatusCode twice, every time. Firstly, shouldn't be an enum as stated above. Secondly, shouldn't be required.


- Ivan Kelly


On April 21, 2014, 5:58 a.m., Sijie Guo wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/17895/
> -----------------------------------------------------------
> 
> (Updated April 21, 2014, 5:58 a.m.)
> 
> 
> Review request for bookkeeper and Ivan Kelly.
> 
> 
> Bugs: BOOKKEEPER-582
>     https://issues.apache.org/jira/browse/BOOKKEEPER-582
> 
> 
> Repository: bookkeeper-git
> 
> 
> Description
> -------
> 
> - introducing protobuf support for bookkeeper
> - for server: introduce packet processor / EnDecoder for different protocol supports
> - for client: change PCBC to use protobuf to send requests
> - misc changes for protobuf support
> 
> (bookie server is able for backward compatibility) 
> 
> 
> Diffs
> -----
> 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/bookie/IndexInMemPageMgr.java 56487aa 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/LedgerChecker.java 28e23d6 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/client/PendingReadOp.java fb36b90 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/processor/RequestProcessor.java 241f369 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieProtoEncoding.java 1154047 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestHandler.java b922a82 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestProcessor.java 8155b22 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookkeeperProtocol.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBase.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBaseV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PerChannelBookieClient.java a10f7d5 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessor.java PRE-CREATION 
>   bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessorV3.java PRE-CREATION 
>   bookkeeper-server/src/main/proto/BookkeeperProtocol.proto PRE-CREATION 
>   bookkeeper-server/src/main/resources/findbugsExclude.xml 97a6156 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/proto/TestProtoVersions.java 5fcc445 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/replication/AuditorPeriodicCheckTest.java 3f8496f 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/BookieClientTest.java bc05229 
>   bookkeeper-server/src/test/java/org/apache/bookkeeper/test/TestBackwardCompat.java 8376b46 
> 
> Diff: https://reviews.apache.org/r/17895/diff/
> 
> 
> Testing
> -------
> 
> unit tests. backward tests.
> 
> 
> Thanks,
> 
> Sijie Guo
> 
>

Re: Review Request 17895: BOOKKEEPER-582: protobuf support for bookkeeper

Posted by Sijie Guo <gu...@gmail.com>.

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/17895/
-----------------------------------------------------------

(Updated April 21, 2014, 5:58 a.m.)


Review request for bookkeeper and Ivan Kelly.


Changes
-------

attach a new patch addressed comments


Bugs: BOOKKEEPER-582
    https://issues.apache.org/jira/browse/BOOKKEEPER-582


Repository: bookkeeper-git


Description
-------

- introducing protobuf support for bookkeeper
- for server: introduce packet processor / EnDecoder for different protocol supports
- for client: change PCBC to use protobuf to send requests
- misc changes for protobuf support

(bookie server is able for backward compatibility) 


Diffs (updated)
-----

  bookkeeper-server/src/main/java/org/apache/bookkeeper/bookie/IndexInMemPageMgr.java 56487aa 
  bookkeeper-server/src/main/java/org/apache/bookkeeper/client/LedgerChecker.java 28e23d6 
  bookkeeper-server/src/main/java/org/apache/bookkeeper/client/PendingReadOp.java fb36b90 
  bookkeeper-server/src/main/java/org/apache/bookkeeper/processor/RequestProcessor.java 241f369 
  bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieProtoEncoding.java 1154047 
  bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestHandler.java b922a82 
  bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieRequestProcessor.java 8155b22 
  bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookkeeperProtocol.java PRE-CREATION 
  bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBase.java PRE-CREATION 
  bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PacketProcessorBaseV3.java PRE-CREATION 
  bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/PerChannelBookieClient.java a10f7d5 
  bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessor.java PRE-CREATION 
  bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/ReadEntryProcessorV3.java PRE-CREATION 
  bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessor.java PRE-CREATION 
  bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/WriteEntryProcessorV3.java PRE-CREATION 
  bookkeeper-server/src/main/proto/BookkeeperProtocol.proto PRE-CREATION 
  bookkeeper-server/src/main/resources/findbugsExclude.xml 97a6156 
  bookkeeper-server/src/test/java/org/apache/bookkeeper/proto/TestProtoVersions.java 5fcc445 
  bookkeeper-server/src/test/java/org/apache/bookkeeper/replication/AuditorPeriodicCheckTest.java 3f8496f 
  bookkeeper-server/src/test/java/org/apache/bookkeeper/test/BookieClientTest.java bc05229 
  bookkeeper-server/src/test/java/org/apache/bookkeeper/test/TestBackwardCompat.java 8376b46 

Diff: https://reviews.apache.org/r/17895/diff/


Testing
-------

unit tests. backward tests.


Thanks,

Sijie Guo