[
https://issues.apache.org/jira/browse/ZOOKEEPER-2019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14108478#comment-14108478
]
Alexander Shraer commented on ZOOKEEPER-2019:
---------------------------------------------
Raul, could you also add a test for this ?
The parsing function checks the first split but has these two statements that
can also fail, without checks:
count = Integer.parseInt(split[0].split("=")[1]);
bytes = Long.parseLong(split[1].split("=")[1]);
perhaps its better to use a Properties object for parsing the string or
something similar, not sure.
Its also weird that updateCount and updateBytes are almost identical and yet
they are two different functions, so create and delete have to call them both
in a sequence doing twice the same things essentially.
> Unhandled exception when setting invalid limits data in
> /zookeeper/quota/some/path/zookeeper_limits
> ----------------------------------------------------------------------------------------------------
>
> Key: ZOOKEEPER-2019
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2019
> Project: ZooKeeper
> Issue Type: Bug
> Components: server
> Reporter: Raul Gutierrez Segales
> Assignee: Raul Gutierrez Segales
> Fix For: 3.5.0
>
> Attachments: ZOOKEEPER-2019.patch
>
>
> If you have quotas properly set for a given path, i.e.:
> {noformat}
> create /zookeeper/quota/test/zookeeper_limits 'count=1,bytes=100'
> create /zookeeper/quota/test/zookeeper_stats 'count=1,bytes=100'
> {noformat}
> and then you update the limits znode with bogus data, i.e.:
> {noformat}
> set /zookeeper/quota/test/zookeeper_limits ''
> {noformat}
> you'll crash the cluster because IllegalArgumentException isn't handled when
> dealing with quotas znodes:
> https://github.com/apache/zookeeper/blob/ZOOKEEPER-823/src/java/main/org/apache/zookeeper/server/DataTree.java#L379
> https://github.com/apache/zookeeper/blob/ZOOKEEPER-823/src/java/main/org/apache/zookeeper/server/DataTree.java#L425
> We should handle IllegalArgumentException. Optionally, we should also throw
> BadArgumentsException from PrepRequestProcessor.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
