pkuwm commented on a change in pull request #1072:
URL: https://github.com/apache/helix/pull/1072#discussion_r459254680
##########
File path:
zookeeper-api/src/main/java/org/apache/helix/zookeeper/zkclient/ZkClient.java
##########
@@ -73,6 +84,10 @@
private static Logger LOG = LoggerFactory.getLogger(ZkClient.class);
private static long MAX_RECONNECT_INTERVAL_MS = 30000; // 30 seconds
+ // Default value for system property jute.maxbuffer
+ // It specifies the maximum size of the data that can be stored in a znode.
+ private static final int DEFAULT_JUTE_MAXBUFFER = 0xfffff;
Review comment:
@jiajunwang For default value 1000KB in ZNRecord SIZE_LIMIT, we still
leave a margin that is 24 KB. But for the value that users config
`jute.maxbuffer`, we should honor it as what is done in ZNRecordSerializer. We
don't leave a margin in ZNRecordSerializer, right? So if user configs
jute.maxbuffer, we expect them to understand it well. Say they already consider
a margin in the value jute.maxbuffer, we should not(users don't expect that,
either) leave another redundant margin.
Say a user sets `jute.maxbuff` to 975KB that they think it already leaves
enough room as margin, we don't want to deduct it again 975 - 24 = 951KB as the
real value. It would also surprise user: if data is 960KB that user expects it
to be written successfully, but it actually fails because of the extra margin.
So for the custom value if a user sets`jute.maxbuff`, I don't think we
should deduct the value with the 24KB margin.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
