[
https://issues.apache.org/jira/browse/ZOOKEEPER-2517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15492392#comment-15492392
]
Michael Han commented on ZOOKEEPER-2517:
----------------------------------------
bq. can we log the warning here and use the default value?
This sounds good as it will be consistent with old client side behavior, where
we don't bail out on bogus just.maxbuffer
{code}
public static final int packetLen = Integer.getInteger("jute.maxbuffer",4096 *
1024);
{code}
On server side, I think the behavior is different, that the server is less
tolerant with bogus configuration value. In most if not all cases server will
not start with bogus value which makes sense as it's better to bail out early
than running into unknown states with bogus configuration.
We could make client behavior consistent with server, so when client has a
bogus maxbuffer config value client will abort?
> jute.maxbuffer is ignored
> -------------------------
>
> Key: ZOOKEEPER-2517
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2517
> Project: ZooKeeper
> Issue Type: Bug
> Affects Versions: 3.5.2
> Reporter: Benjamin Jaton
> Assignee: Arshad Mohammad
> Priority: Blocker
> Fix For: 3.5.3, 3.6.0
>
> Attachments: ZOOKEEPER-2517-01.patch, ZOOKEEPER-2517-02.patch,
> ZOOKEEPER-2517-03.patch, ZOOKEEPER-2517.patch
>
>
> In ClientCnxnSocket.java the parsing of the system property is erroneous:
> {code}packetLen = Integer.getInteger(
> clientConfig.getProperty(ZKConfig.JUTE_MAXBUFFER),
> ZKClientConfig.CLIENT_MAX_PACKET_LENGTH_DEFAULT
> );{code}
> Javadoc of Integer.getInteger states "The first argument is treated as the
> name of a system property", whereas here the value of the property is passed.
> Instead I believe the author meant to write something like:
> {code}packetLen = Integer.parseInt(
> clientConfig.getProperty(
> ZKConfig.JUTE_MAXBUFFER,
> String.valueOf(ZKClientConfig.CLIENT_MAX_PACKET_LENGTH_DEFAULT)
> )
> );{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
