> On April 19, 2017, 5:07 p.m., Anand Mazumdar wrote:
> > src/tests/protobuf_utils_tests.cpp
> > Lines 289 (patched)
> > <https://reviews.apache.org/r/58360/diff/3/?file=1694372#file1694372line289>
> >
> >     Can you add a comment around why we added this test?
> 
> Chun-Hung Hsiao wrote:
>     It seems to me that if we don't want to enforce a hard dependency on 
> protobuf-3.x, we should not add it.

I don't mind taking out the test, but I definitely need to make sure we are 
committed to supporting large message (>64MB).

The only alternative I can see is to ensure we have proper API design to 
paginate any potential protobuf message which could go large within the 64MB 
limit imposed by protobuf2.

AFAIK both `GET_STATE` and `OFFERS` messages could exceed this and render the 
cluster not usable for an important use case.

Do you have any concern about a hard dependency to protobuf 3.x?


- Zhitao


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


On April 19, 2017, 4:23 p.m., Zhitao Li wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58360/
> -----------------------------------------------------------
> 
> (Updated April 19, 2017, 4:23 p.m.)
> 
> 
> Review request for mesos and Anand Mazumdar.
> 
> 
> Bugs: MESOS-6644 and MESOS-7228
>     https://issues.apache.org/jira/browse/MESOS-6644
>     https://issues.apache.org/jira/browse/MESOS-7228
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> Before protobuf 3.2.0, this test would fail because the 64MB limit
> imposed by older version of protobuf.
> 
> 
> Diffs
> -----
> 
>   src/tests/protobuf_utils_tests.cpp 5239182812835b93a28e85146b2df2b20ae77328 
> 
> 
> Diff: https://reviews.apache.org/r/58360/diff/3/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Zhitao Li
> 
>

Reply via email to