Re: Does ZK use protobuf?
Il Mer 8 Apr 2020, 06:18 tison ha scritto: > From the git history I think it is just old and need to be updated. > > FYI, there is an ongoing effort ZOOKEEPER-102 trying to add protobuf as an > option for serde and finally deprecated jute. > > Best, > tison. > > > Christopher 于2020年4月8日周三 上午11:25写道： > > > Does ZooKeeper use, or have any generated code using protocol buffers? > > > > I ask because zookeeper-server/src/main/resources/NOTICE.txt Good catch! (master > > branch, 3.7.0-SNAPSHOT) references it as an optional dependency, but I > > can't find any '*.proto' source files or any code that looks like it > > was generated with protobuf. > We are not using it. We should remove that information. Enrico > > > Is this just old and need to be updated? > > > > Thanks, > > Christopher > > >
Re: Does ZK use protobuf?
>From the git history I think it is just old and need to be updated. FYI, there is an ongoing effort ZOOKEEPER-102 trying to add protobuf as an option for serde and finally deprecated jute. Best, tison. Christopher 于2020年4月8日周三 上午11:25写道： > Does ZooKeeper use, or have any generated code using protocol buffers? > > I ask because zookeeper-server/src/main/resources/NOTICE.txt (master > branch, 3.7.0-SNAPSHOT) references it as an optional dependency, but I > can't find any '*.proto' source files or any code that looks like it > was generated with protobuf. > > Is this just old and need to be updated? > > Thanks, > Christopher >
Does ZK use protobuf?
Does ZooKeeper use, or have any generated code using protocol buffers? I ask because zookeeper-server/src/main/resources/NOTICE.txt (master branch, 3.7.0-SNAPSHOT) references it as an optional dependency, but I can't find any '*.proto' source files or any code that looks like it was generated with protobuf. Is this just old and need to be updated? Thanks, Christopher
[jira] [Created] (ZOOKEEPER-3787) Apply modernizer-maven-plugin to build
Christopher Tubbs created ZOOKEEPER-3787: Summary: Apply modernizer-maven-plugin to build Key: ZOOKEEPER-3787 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3787 Project: ZooKeeper Issue Type: Improvement Components: build Reporter: Christopher Tubbs Assignee: Christopher Tubbs Fix For: 3.7.0 modernizer-maven-plugin can catch outdated Java coding paradigms that have been superseded by newer Java language features. Applying the recommended changes from this plugin can help a project avoid breakages, incompatibilities, and changes in behavior, across Java versions. It can also help reduce dependencies by suggesting changes that leverage built-in Java classes rather than commonly-used external libraries that were written to add convenient features before those features were added to Java itself. Adding the plugin to the build is simple, but working through all the items it catches is tedious. I've already begun this work. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: Implement checksum against malformed packets
>> but not bulletproof? tcp checksum is weak and can't detect all corrupt packet; and bit flip can happen anywhere within the stack, and can be caused by malfunction of ram, or say, cosmic rays. Statistically a corrupt packet survives all layers of check is low, and even a packet is corrupted, app layer behavior might still be ok. >> wire encryption probably resolves it for free. This would be my recommendation here as well to ensure data integrity during transmission. Checksum itself (even cryptographic checksum) can't guarantee data integrity as packet in flight can be altered along with the new checksum. On Tue, Apr 7, 2020 at 1:37 AM Andor Molnar wrote: > Hi Zk community, > > I’ve been looking at the following ticket for a while and made me thinking: > ZOOKEEPER-2175 Checksum validation for malformed packets needs to handle. > https://issues.apache.org/jira/browse/ZOOKEEPER-2175 > > It has been found in 3.4.6 originally and not resolved since then saying > that wire encryption probably resolves it for free. I have doubts against > the issue could actually happen at all, but the evidence in the jira is > quite convincing. > > 1) But what if somebody don’t want the overhead of using encryption? > 2) How often this issue could ever happen given that TCP packets have > their own checksum which also protects the payload, but not bulletproof? > 3) Found a suggestion in a comment to send session id in the payload of > Ping packets, but malformed packets could happen in any other > communication, not just session ids. > 4) Does GRPC have a built-in mechanism to protect the communication? Maybe > this would be the best way forward. > > What do you think? > > Andor > > >
[jira] [Created] (ZOOKEEPER-3786) Simplify generation of VersionInfoMain and Info
Christopher Tubbs created ZOOKEEPER-3786: Summary: Simplify generation of VersionInfoMain and Info Key: ZOOKEEPER-3786 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3786 Project: ZooKeeper Issue Type: Improvement Components: build Reporter: Christopher Tubbs Assignee: Christopher Tubbs Fix For: 3.7.0 The VerGen command is currently compiled and executed in a separate step prior to compilation of the rest of zookeeper-server. This is wasteful, complicated, and unnecessary. Maven has built-in resource filtering for classes, so you can inject the system properties into the build and generate sources to be compiled that have the necessary information. (For example, see Accumulo's FilteredConstants). I have a pull request ready to address this, which I will push up shortly. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: ZK does not compile on JDK14 due to "java.lang.Record"
Please check my patch
https://github.com/apache/zookeeper/pull/1308
I would like to add it to 3.6.1 before a release
Enrico
Il giorno ven 27 mar 2020 alle ore 17:55 Enrico Olivelli
ha scritto:
>
>
>
> Il Ven 27 Mar 2020, 17:43 Jordan Zimmerman ha
> scritto:
>>
>> Boy - it seems it's a mistake for the JDK to have Record in the java.lang
>> package. Putting it in a different package would fix this. I wonder if we
>> should file a bug or bring it up on the Amber list?
>
>
> I am following that group.
> It was a decision made by intent. They won't change. That class is like
> java.lang.Object.
>
> It is only a source compatibility issue not at runtime. So not a big deal
>
> Enrico
>
>>
>> -Jordan
>>
>> > On Mar 27, 2020, at 11:26 AM, Enrico Olivelli wrote:
>> >
>> > Let me file and INFRA issue and a patch for jute
>> >
>> > Stay tuned
>> >
>> > Enrico
>> >
>> > Il Ven 27 Mar 2020, 17:03 Patrick Hunt ha scritto:
>> >
>> >> Confirmed locally with oracle jdk 14 and zk trunk.
>> >>
>> >> Patrick
>> >>
>> >> On Fri, Mar 27, 2020 at 6:19 AM Enrico Olivelli
>> >> wrote:
>> >>
>> >>> Il giorno gio 26 mar 2020 alle ore 23:45 Patrick Hunt
>> >>> ha scritto:
>>
>> Seems the new JEP 359 record feature is added to jdk14 as a preview and
>> it's introduced a regression wrt our "Record"
>> https://openjdk.java.net/jeps/359
>>
>> So two things then - we should disambiguate our Record and see why the
>> jenkins job is not seeing this... odd.
>> >>>
>> >>> Maybe Jenkins has an early version of JDK14 without records support
>> >>>
>> >>> having a mvn -v on jenkins will help
>> >>>
>> >>> Can anyone try locally ?
>> >>> You can download the jdk and use it just by unpacking the tar.gz file,
>> >>> no need to "install" it
>> >>>
>> >>> Enrico
>> >>>
>>
>> Patrick
>>
>>
>> On Thu, Mar 26, 2020 at 3:26 PM Enrico Olivelli
>> >>> wrote:
>>
>> > Patrick
>> > you are right
>> > it looks like it is using "/home/jenkins/tools/java/latest14"
>> >
>> > this is my maven version info:
>> >
>> > [eolivelli@localhost target]$ mvn -v
>> > Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
>> > Maven home: /home/eolivelli/dev/maven
>> > Java version: 14, vendor: AdoptOpenJDK, runtime:
>> > /home/eolivelli/dev/jdk-14+36
>> > Default locale: en_US, platform encoding: UTF-8
>> > OS name: "linux", version: "5.5.10-200.fc31.x86_64", arch: "amd64",
>> > family: "unix"
>> >
>> > we should add some "mvn -v" to be executed as a pre build step
>> >
>> > Enrico
>> >
>> > Il giorno gio 26 mar 2020 alle ore 23:22 Patrick Hunt
>> > ha scritto:
>> >>
>> >> The jenkins job for jdk14 is passing - any ideas why you are seeing
>> >> different? Is the jenkins job setup incorrectly?
>> >>
>> >>
>> >
>> >>>
>> >> https://builds.apache.org/view/Z/view/ZooKeeper/job/zookeeper-master-maven-jdk14/
>> >>
>> >> Patrick
>> >>
>> >>
>> >> On Thu, Mar 26, 2020 at 3:13 PM Enrico Olivelli <
>> >> eolive...@gmail.com
>>
>> > wrote:
>> >>
>> >>> Hi,
>> >>> it looks like ZK cannot be build on JDK14 due to a small source
>> >>> compatibility issue.
>> >>> The error is below.
>> >>>
>> >>> The fix is trivial, we just only have to explicitly import the
>> >> full
>> >>> classname of "Record"
>> >>>
>> >>> Enrico
>> >>>
>> >>> both interface org.apache.jute.Record in org.apache.jute and
>> >> class
>> >>> java.lang.Record in java.lang match
>> >>> [ERROR]
>> >>>
>> >
>> >>>
>> >> /home/eolivelli/dev/zookeeper/zookeeper-jute/target/generated-sources/java/org/apache/zookeeper/proto/GetMaxChildrenResponse.java:25:
>> >>> error: reference to Record is ambiguous
>> >>> [ERROR] public class GetMaxChildrenResponse implements Record {
>> >>>
>> >
>> >>>
>> >>
>>
[jira] [Created] (ZOOKEEPER-3785) Make sources buildable with JDK14
Enrico Olivelli created ZOOKEEPER-3785: -- Summary: Make sources buildable with JDK14 Key: ZOOKEEPER-3785 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3785 Project: ZooKeeper Issue Type: Improvement Components: build Affects Versions: 3.5.7 Reporter: Enrico Olivelli Assignee: Enrico Olivelli Fix For: 3.7.0, 3.6.1, 3.5.8 JDK14 adds java.lang.Record and so Jute generated files need an explicit import of Jute Record class. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Implement checksum against malformed packets
Hi Zk community, I’ve been looking at the following ticket for a while and made me thinking: ZOOKEEPER-2175 Checksum validation for malformed packets needs to handle. https://issues.apache.org/jira/browse/ZOOKEEPER-2175 It has been found in 3.4.6 originally and not resolved since then saying that wire encryption probably resolves it for free. I have doubts against the issue could actually happen at all, but the evidence in the jira is quite convincing. 1) But what if somebody don’t want the overhead of using encryption? 2) How often this issue could ever happen given that TCP packets have their own checksum which also protects the payload, but not bulletproof? 3) Found a suggestion in a comment to send session id in the payload of Ping packets, but malformed packets could happen in any other communication, not just session ids. 4) Does GRPC have a built-in mechanism to protect the communication? Maybe this would be the best way forward. What do you think? Andor
