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
Conversation
Signed-off-by: tison <wander4096@gmail.com>
Signed-off-by: tison <wander4096@gmail.com>
This reverts commit 6fc15a7.
Signed-off-by: tison <wander4096@gmail.com>
Signed-off-by: tison <wander4096@gmail.com>
Signed-off-by: tison <wander4096@gmail.com>
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>
zookeeper-server/src/main/java/org/apache/zookeeper/server/PrepRequestProcessor.java
Show resolved
Hide resolved
zookeeper-server/src/main/java/org/apache/zookeeper/server/PrepRequestProcessor.java
Outdated
Show resolved
Hide resolved
zookeeper-server/src/main/java/org/apache/zookeeper/server/PrepRequestProcessor.java
Show resolved
Hide resolved
…hange is OK Signed-off-by: tison <wander4096@gmail.com>
zookeeper-server/src/main/java/org/apache/zookeeper/server/quorum/QuorumZooKeeperServer.java
Show resolved
Hide resolved
zookeeper-server/src/main/java/org/apache/zookeeper/server/ContainerManager.java
Outdated
Show resolved
Hide resolved
Signed-off-by: tison <wander4096@gmail.com>
Signed-off-by: tison <wander4096@gmail.com>
zookeeper-server/src/main/java/org/apache/zookeeper/server/ByteBufferRequestRecord.java
Outdated
Show resolved
Hide resolved
zookeeper-server/src/main/java/org/apache/zookeeper/server/ByteBufferRequestRecord.java
Outdated
Show resolved
Hide resolved
zookeeper-server/src/main/java/org/apache/zookeeper/server/ByteBufferRequestRecord.java
Outdated
Show resolved
Hide resolved
@@ -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) { |
There was a problem hiding this comment.
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 ?
There was a problem hiding this comment.
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;
}
}
Signed-off-by: tison <wander4096@gmail.com>
CI failed. Although I don't think it's related. Will retry later.
|
Signed-off-by: tison <wander4096@gmail.com>
There was a problem hiding this 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.
I tried to re-trigger CI. Seems to be some JAVA_HOME setup issue on the CI server? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great work. @tisonkun !
@symat I don't have to completed performance coverage on this change. From the code change perspective:
|
There was a problem hiding this 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
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. |
CI still fails with the same java environment problem. I wonder if it affects also other PRs. Could maybe a rebase help here? |
@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, |
There was a problem hiding this comment.
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 ]
|
@symat unfortunately, it seems no help :( |
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>
@symat Fixed now. Please help with merging :) cc @eolivelli |
cool, thanks @tisonkun ! |
+1 to merge |
merged to the master branch. Thank you @tisonkun for your contribution! |
Thank you! |
…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
…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>
This is the first step mentioned in ZOOKEEPER-102 and we should not play with ByteBuffer among the request handling code path.