[
https://issues.apache.org/jira/browse/ZOOKEEPER-1473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13892486#comment-13892486
]
Raul Gutierrez Segales commented on ZOOKEEPER-1473:
---------------------------------------------------
Some nits:
{noformat}
+ public static final String COMMIT_LOG_COUNT = "zoookeeper.commitLogCount";
{noformat}
typo: zookeeper
{noformat}
+ LOG.info(COMMIT_LOG_COUNT+ "=" + commitLogCount);
{noformat}
can we have string extrapolation instead of concatenation (more readable, easy
to do mass changes if you want to change the LOG calls, etc):
{noformat}
+ LOG.info("{} = {}", COMMIT_LOG_COUNT, commitLogCount);
{noformat}
> Committed proposal log retains triple the memory it needs to
> ------------------------------------------------------------
>
> Key: ZOOKEEPER-1473
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1473
> Project: ZooKeeper
> Issue Type: Bug
> Components: server
> Reporter: Henry Robinson
> Assignee: Thawan Kooburat
> Fix For: 3.5.0
>
> Attachments: ZOOKEEPER-1473.patch, ZOOKEEPER-1473.patch
>
>
> ZKDatabase.committedLog retains the past 500 transactions to enable fast
> catch-up. This works great, but it's using triple the memory it needs to by
> retaining three copies of the data part of any transaction.
> * The first is in committedLog[i].request.request.hb - a heap-allocated
> {{ByteBuffer}}.
> * The second is in committedLog[i].request.txn.data - a jute-serialised
> record of the transaction
> * The third is in committedLog[i].packet.data - also jute-serialised,
> seemingly uninitialised data.
> This means that a ZK-server could be using 1G of memory more than it should
> be in the worst case. We should use just one copy of the data, even if we
> really have to refer to it 3 times.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
