Hi Sijie, I just want to clarify if it is to upgrade protobuf 2 to 3. Would that lead to a backward compatibility issue for clients? Proto3 has removed the custom default, which pulsar api proto uses, and a few others in proto 2. Would that be a concern for clients?
Ming On Fri, 22 May 2020 at 13:52, Sijie Guo <guosi...@gmail.com> wrote: > Hi all, > > I would like to kick off a discussion about what we should do for protobuf > 2.4.1 and figure out what is the long term plan. > > Currently, Pulsar is using a customized version of protobuf 2.4.1 for wire > protocol. The customization was made to leverage netty object pooling to > reduce object generation and cause bad JVM GC behavior. However, protobuf > 2.4.1 is a many-years old release and there is also a vulnerability issue > reported for protobuf-java 2.4.1 ( > https://nvd.nist.gov/vuln/detail/CVE-2015-5237). We need to figure out a > plan to upgrade this dependency. > > Here are some thoughts. Happy to see what others think. > > a) We upgrade to protobuf 3.x without customization. > > - Pros: be able to catch up with changes in protobuf and avoid any > vulnerabilities. > - Cons: we might have to suffer the pains from object generations. But it > might not be too bad since we don't store the message payloads in protobuf. > > b) We upgrade to protobuf 3.x with new customization. > > - Pros: We are able to control object generations. > - Cons: Maintaining a customization makes harder to catch up changes in > protobuf community and avoid vulnerabilities. > > c) Look for other alternatives to protobuf such as flatbuffers. > > - Cons: it is not a backward-compatible solution with existing Pulsar > clients. > > - Sijie > -- Powered by Pulsar Engineering, Kafkaesque
