[
https://issues.apache.org/jira/browse/ZOOKEEPER-2940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16443826#comment-16443826
]
ASF GitHub Bot commented on ZOOKEEPER-2940:
-------------------------------------------
Github user anmolnar commented on a diff in the pull request:
https://github.com/apache/zookeeper/pull/466#discussion_r182698169
--- Diff:
src/java/main/org/apache/zookeeper/server/command/MonitorCommand.java ---
@@ -75,9 +79,9 @@ public void commandRun() {
print("synced_followers",
leader.getForwardingFollowers().size());
print("pending_syncs", leader.getNumPendingSyncs());
- print("last_proposal_size",
leader.getProposalStats().getLastProposalSize());
- print("max_proposal_size",
leader.getProposalStats().getMaxProposalSize());
- print("min_proposal_size",
leader.getProposalStats().getMinProposalSize());
+ print("last_proposal_size",
leader.getProposalStats().getLast());
--- End diff --
You're right about stats will evolve with time, but proposal and client
request size are common in Jute buffer usage. I have a strong feeling that
these two things will always evolve together hence it makes sense to keep the
stats together which also makes refactoring easier. Later, if it turns out that
they diverge, we can easily split them.
> Deal with maxbuffer as it relates to large requests from clients
> ----------------------------------------------------------------
>
> Key: ZOOKEEPER-2940
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2940
> Project: ZooKeeper
> Issue Type: Sub-task
> Components: jute, server
> Reporter: Andor Molnar
> Assignee: Andor Molnar
> Priority: Major
> Fix For: 3.5.4, 3.6.0
>
>
> Monitor real-time Jute buffer usage as it relates to large requests from
> clients.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
