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? Regards, Andor On Sat, Apr 7, 2018 at 8:13 PM, Shawn Heisey <[email protected]> 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 > >
