ivmaykov commented on a change in pull request #753: ZOOKEEPER-3204: Reconfig
tests are constantly failing on 3.5 after applying Java 11 fix
URL: https://github.com/apache/zookeeper/pull/753#discussion_r254336981
##########
File path:
zookeeper-server/src/main/java/org/apache/zookeeper/server/NettyServerCnxn.java
##########
@@ -307,19 +281,126 @@ private boolean checkFourLetterWord(final Channel
channel,
}
}
- public void receiveMessage(ChannelBuffer message) {
+ /**
+ * Process incoming message. This should only be called from the event
+ * loop thread.
+ * @param buf the message bytes to process.
+ */
+ void processMessage(ByteBuf buf) {
+ assert channel.eventLoop().inEventLoop();
+ if (LOG.isDebugEnabled()) {
+ LOG.debug("0x{} queuedBuffer: {}",
+ Long.toHexString(sessionId),
+ queuedBuffer);
+ }
+
+ if (LOG.isTraceEnabled()) {
+ LOG.trace("0x{} buf {}",
+ Long.toHexString(sessionId),
+ ByteBufUtil.hexDump(buf));
+ }
+
+ if (throttled.get()) {
+ LOG.debug("Received message while throttled");
+ // we are throttled, so we need to queue
+ if (queuedBuffer == null) {
+ LOG.debug("allocating queue");
+ queuedBuffer = channel.alloc().buffer(buf.readableBytes());
+ }
+ queuedBuffer.writeBytes(buf);
+ if (LOG.isTraceEnabled()) {
+ LOG.trace("0x{} queuedBuffer {}",
+ Long.toHexString(sessionId),
+ ByteBufUtil.hexDump(queuedBuffer));
+ }
+ } else {
+ LOG.debug("not throttled");
+ if (queuedBuffer != null) {
+ queuedBuffer.writeBytes(buf);
+ processQueuedBuffer();
+ } else {
+ receiveMessage(buf);
+ // Have to check !closingChannel, because an error in
+ // receiveMessage() could have led to close() being called.
+ if (!closingChannel && buf.isReadable()) {
+ if (LOG.isTraceEnabled()) {
+ LOG.trace("Before copy {}", buf);
+ }
+ if (queuedBuffer == null) {
+ queuedBuffer =
channel.alloc().buffer(buf.readableBytes());
+ }
+ queuedBuffer.writeBytes(buf);
+ if (LOG.isTraceEnabled()) {
+ LOG.trace("Copy is {}", queuedBuffer);
+ LOG.trace("0x{} queuedBuffer {}",
+ Long.toHexString(sessionId),
+ ByteBufUtil.hexDump(queuedBuffer));
+ }
+ }
+ }
+ }
+ }
+
+ /**
+ * Try to process previously queued message. This should only be called
+ * from the event loop thread.
+ */
+ void processQueuedBuffer() {
+ assert channel.eventLoop().inEventLoop();
+ if (queuedBuffer != null) {
+ if (LOG.isTraceEnabled()) {
+ LOG.trace("processing queue 0x{} queuedBuffer {}",
+ Long.toHexString(sessionId),
+ ByteBufUtil.hexDump(queuedBuffer));
+ }
+ receiveMessage(queuedBuffer);
+ if (closingChannel) {
+ // close() could have been called if receiveMessage() failed
+ LOG.debug("Processed queue - channel closed, dropping
remaining bytes");
+ } else if (!queuedBuffer.isReadable()) {
+ LOG.debug("Processed queue - no bytes remaining");
+ releaseQueuedBuffer();
+ } else {
+ LOG.debug("Processed queue - bytes remaining");
Review comment:
I don't think this will cause an OOM in most cases, as most client requests
will not send a lot of data, and once all of the incoming data is consumed the
buffer will be freed. I guess if there are many clients, and each is writing a
lot of data to a znode, it could increase memory usage. But I think the most
data that can be stored in a znode is 1MB, so assuming even 10k concurrent
clients each writing 1MB that is 10GB of memory. It's a lot, but this is a
pretty extreme case and modern servers can easily have hundreds of GB.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
With regards,
Apache Git Services
