Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ZOOKEEPER-4575: ZooKeeperServer#processPacket take record instead of bytes #1905

Closed
wants to merge 24 commits into from

Conversation

tisonkun
Copy link
Member

@tisonkun tisonkun commented Jul 17, 2022

This is the first step mentioned in ZOOKEEPER-102 and we should not play with ByteBuffer among the request handling code path.

Signed-off-by: tison <wander4096@gmail.com>
Signed-off-by: tison <wander4096@gmail.com>
Signed-off-by: tison <wander4096@gmail.com>
Signed-off-by: tison <wander4096@gmail.com>
Signed-off-by: tison <wander4096@gmail.com>
@tisonkun
Copy link
Member Author

Verifying that we're in a good state. Will push further refactor logics.

Signed-off-by: tison <wander4096@gmail.com>
Signed-off-by: tison <wander4096@gmail.com>
Signed-off-by: tison <wander4096@gmail.com>
Signed-off-by: tison <wander4096@gmail.com>
Signed-off-by: tison <wander4096@gmail.com>
Signed-off-by: tison <wander4096@gmail.com>
Signed-off-by: tison <wander4096@gmail.com>
Signed-off-by: tison <wander4096@gmail.com>
…hange is OK

Signed-off-by: tison <wander4096@gmail.com>
Signed-off-by: tison <wander4096@gmail.com>
Signed-off-by: tison <wander4096@gmail.com>
@tisonkun tisonkun changed the title WIP - ZooKeeperServer#processPacket take record instead of bytes ZOOKEEPER-4575: ZooKeeperServer#processPacket take record instead of bytes Jul 20, 2022
@tisonkun
Copy link
Member Author

cc @eolivelli @symat @anmolnar

@@ -359,9 +355,6 @@ protected void pRequest2Txn(int type, long zxid, Request request, Record record,
case OpCode.delete:
zks.sessionTracker.checkSession(request.sessionId, request.getOwner());
DeleteRequest deleteRequest = (DeleteRequest) record;
if (deserialize) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this a behaviour change ? were is the deserialisation happening ?
are we doing it more times now ?

Copy link
Member Author

@tisonkun tisonkun Sep 3, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No. Previously we need this boolean flag because, after deserializing MultiOperationRecord, the subrequest is an in-memory data structure - there are no more bytes in the request to be deserialized.

Now, we always deserialize in pRequestHelper, no serialization happens in pRequest2Txn. Besides, we always serialize at most once in RequestRecord:

public class ByteBufferRequestRecord {
    @Override
    public <T extends Record> T readRecord(Supplier<T> constructor) throws IOException {
        if (record != null) {
            return (T) record;
        }
        // deserialization
    }
}

public class SimpleRequestRecord {
    @Override
    public <T extends Record> T readRecord(Supplier<T> constructor) {
        return (T) record;
    }
}

@tisonkun
Copy link
Member Author

tisonkun commented Sep 3, 2022

CI failed. Although I don't think it's related. Will retry later.

$ java -Xmx32m -version
openjdk version "11.0.16.1" 2022-08-12 LTS
OpenJDK Runtime Environment (build 11.0.16.1+1-LTS)
OpenJDK 64-Bit Server VM (build 11.0.16.1+1-LTS, mixed mode)
$ javac -J-Xmx32m -version
javac 11.0.16.1
install
12.82s$ if [ "${TRAVIS_CPU_ARCH}" == "arm64" ]; then sudo apt-get install maven; fi
0.08s$ mvn clean apache-rat:check verify -DskipTests spotbugs:check checkstyle:check -Pfull-build
Error: JAVA_HOME is not defined correctly.
  We cannot execute /usr/lib/jvm/bellsoft-java11-arm64/bin/java
The command "mvn clean apache-rat:check verify -DskipTests spotbugs:check checkstyle:check -Pfull-build" exited with 1.

Signed-off-by: tison <wander4096@gmail.com>
@tisonkun
Copy link
Member Author

ping @eolivelli @symat @anmolnar @maoling

Copy link
Contributor

@symat symat left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @tisonkun for the PR and sorry for the (very) late response. I went through the change, looks good to me. I like the new abstraction.

Should we fear of any performance degradation? I think it is unlikely, but I haven't spent enough time on the PR to be sure and want to hear your opinion.

@symat
Copy link
Contributor

symat commented Sep 27, 2022

I tried to re-trigger CI. Seems to be some JAVA_HOME setup issue on the CI server?

Copy link
Contributor

@eolivelli eolivelli left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great work. @tisonkun !

@tisonkun
Copy link
Member Author

tisonkun commented Oct 2, 2022

Should we fear of any performance degradation? I think it is unlikely, but I haven't spent enough time on the PR to be sure and want to hear your opinion.

@symat I don't have to completed performance coverage on this change. From the code change perspective:

  1. RequestRecord (ByteBufferRequestRecord) is a semantically identical refactoring over current codebase.
  2. About changing about the deserialization part during PrepProcessor, see ZOOKEEPER-4575: ZooKeeperServer#processPacket take record instead of bytes #1905 (comment).

Copy link
Contributor

@symat symat left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, looks good to me

@symat
Copy link
Contributor

symat commented Oct 3, 2022

Not related to this PR necessarily, but it would be nice to come up with some simple reproducible perf test later. Especially because this is part of a larger refactoring and in the end we should see if we have any degradation with Jute and also to compare Jute with any other protocol we choose later.

@symat
Copy link
Contributor

symat commented Oct 3, 2022

CI still fails with the same java environment problem. I wonder if it affects also other PRs. Could maybe a rebase help here?

@tisonkun
Copy link
Member Author

tisonkun commented Oct 4, 2022

@symat Thanks for your follow-up. I'm merging the lastest master.

@@ -387,9 +380,6 @@ protected void pRequest2Txn(int type, long zxid, Request request, Record record,
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💬 2 similar findings have been found in this PR


THREAD_SAFETY_VIOLATION: Read/Write race. Non-private method PrepRequestProcessor.pRequest2Txn(...) indirectly reads without synchronization from auth.ProviderRegistry.initialized. Potentially races with write in method PrepRequestProcessor.pRequest2Txn(...).
Reporting because this access may occur on a background thread.


🔎 Expand here to view all instances of this finding
File Path Line Number
zookeeper-server/src/main/java/org/apache/zookeeper/server/PrepRequestProcessor.java 326
zookeeper-server/src/main/java/org/apache/zookeeper/server/PrepRequestProcessor.java 317

Visit the Lift Web Console to find more details in your report.


ℹ️ Learn about @sonatype-lift commands

You can reply with the following commands. For example, reply with @sonatype-lift ignoreall to leave out all findings.

Command Usage
@sonatype-lift ignore Leave out the above finding from this PR
@sonatype-lift ignoreall Leave out all the existing findings from this PR
@sonatype-lift exclude <file|issue|path|tool> Exclude specified file|issue|path|tool from Lift findings by updating your config.toml file

Note: When talking to LiftBot, you need to refresh the page to see its response.
Click here to add LiftBot to another repo.


Was this a good recommendation?
[ 🙁 Not relevant ] - [ 😕 Won't fix ] - [ 😑 Not critical, will fix ] - [ 🙂 Critical, will fix ] - [ 😊 Critical, fixing now ]

@sonatype-lift
Copy link

sonatype-lift bot commented Oct 4, 2022

⚠️ 52 God Classes were detected by Lift in this project. Visit the Lift web console for more details.

@tisonkun
Copy link
Member Author

tisonkun commented Oct 5, 2022

@symat unfortunately, it seems no help :(

@tisonkun
Copy link
Member Author

tisonkun commented Oct 5, 2022

Let me try to update the travis config file...

Signed-off-by: tison <wander4096@gmail.com>
Signed-off-by: tison <wander4096@gmail.com>
Signed-off-by: tison <wander4096@gmail.com>
@tisonkun
Copy link
Member Author

tisonkun commented Oct 5, 2022

@symat Fixed now. Please help with merging :)

cc @eolivelli

@symat
Copy link
Contributor

symat commented Oct 5, 2022

cool, thanks @tisonkun !
@eolivelli - do you think it is OK if I go ahead and merge this? Having travis fix mixed up with the refactoring might not be nice, but on the other hand we won't cherry pick this one to other branches anyway.

@eolivelli
Copy link
Contributor

+1 to merge

@asfgit asfgit closed this in 3daefac Oct 5, 2022
@symat
Copy link
Contributor

symat commented Oct 5, 2022

merged to the master branch. Thank you @tisonkun for your contribution!

@tisonkun tisonkun deleted the request-supplier branch October 5, 2022 16:07
@tisonkun
Copy link
Member Author

tisonkun commented Oct 5, 2022

Thank you!

anuragmadnawat1 pushed a commit to anuragmadnawat1/zookeeper that referenced this pull request Nov 2, 2022
…bytes

This is the first step mentioned in [ZOOKEEPER-102](https://issues.apache.org/jira/browse/ZOOKEEPER-102) and we should not play with ByteBuffer among the request handling code path.

Author: tison <wander4096@gmail.com>

Reviewers: Enrico Olivelli <eolivelli@apache.org>, Mate Szalay-Beko <symat@apache.org>

Closes apache#1905 from tisonkun/request-supplier
anuragmadnawat1 added a commit to anuragmadnawat1/zookeeper that referenced this pull request Nov 2, 2022
…bytes (#79)

This is the first step mentioned in [ZOOKEEPER-102](https://issues.apache.org/jira/browse/ZOOKEEPER-102) and we should not play with ByteBuffer among the request handling code path.

Author: tison <wander4096@gmail.com>

Reviewers: Enrico Olivelli <eolivelli@apache.org>, Mate Szalay-Beko <symat@apache.org>

Closes apache#1905 from tisonkun/request-supplier

Co-authored-by: tison <wander4096@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants