zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andor Molnar <an...@cloudera.com>
Subject Re: Is the current max packet length available via the API?
Date Mon, 09 Apr 2018 08:29:26 GMT
If the ZK client is part of your application, you can probably read the
jute.maxbuffer setting.

However on the server side - as you mentioned - the setting should be
consistent with the client. I believe it would make sense to expose the
effective jute maxbuffer size via the "conf" 4lw command if that's any help
to you.

Would you like to contribute and submit a pull request for that on the
master branch?


On Sat, Apr 7, 2018 at 8:13 PM, Shawn Heisey <elyograg@elyograg.org> wrote:

> On 4/6/2018 6:46 AM, Martin Gainty wrote:
>      ZOOMAIN="-Dcom.sun.management.jmxremote
>> -Dcom.sun.management.jmxremote.port=$JMXPORT
>> -Dcom.sun.management.jmxremote.authenticate=$JMXAUTH
>> -Dcom.sun.management.jmxremote.ssl=$JMXSSL -Dzookeeper.jmx.log4j.disable=$JMXLOG4J
>> org.apache.zookeeper.server.quorum.QuorumPeerMain"
>>    fi
>> else
>>      echo "JMX disabled by user request" >&2
>>      ZOOMAIN="org.apache.zookeeper.server.quorum.QuorumPeerMain"
>> fi
>> MG>everything you need to setup JMX is located MG>athttp://
>> java.sun.com/javase/6/docs/technotes/guides/management/agent.html
> I know how to enable remote JMX when running a java program. I also know
> how to connect a JMX client like jconsole to that program.
> What I was saying that I didn't know how to do was access data from JMX in
> a Java program that I've written myself.
> Remote JMX seems like overkill, when all I want to know is what the ZK
> client that's part of my application is currently using as a maximum packet
> length.  Reading ClientCnxn.packetLen gets me what I was after.  It would
> have taken an extensive code review for me to find that particular field,
> so thank you for letting me know about it.
> If the client has an increased jute.maxbuffer but the server doesn't, then
> there could still be a problem with writing data, but I'm not going to try
> and detect that.  In any case, I'm not going to abort the upload, I'm just
> logging a warning.
> Thanks,
> Shawn

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message