我正在使用Grizzly 2.3.22及其Websocket支持开发一个项目。在OOM发生之前，一切都很好。通过转储我发现所有内存都被一个org.glassfish.grizzly.nio.transport.TCPNIOConnection占用了一个巨大的（1,5GB）写入队列。我想其中一个客户端开发人员正在调试他们的连接应用程序并在断点上停留了很长时间。无论如何，如果客户端连接速度很慢，很容易发生这种情况 - 我的服务器应该为此做好准备。
在Grizzly documentation我找到了 maxPendingBytes 属性，这似乎是一个解决方案，至少目前是这样。但我根本无法让它工作。我将AbstractNIOAsyncQueueWriter的日志级别设置为ALL，与客户端连接，将其置于保持状态并观察服务器队列如何增长：
TRACE 2016-07-05 21:02:26.330 [nioEventLoopGroup-2-1] o.g.g.n.AbstractNIOAsyncQueueWriter - AsyncQueueWriter.write connection=TCPNIOConnection{localSocketAddress={/127.0.0.1:8445}, peerSocketAddress={/127.0.0.1:56185}}, record=org.glassfish.grizzly.asyncqueue.AsyncWriteQueueRecord@1e35bafb, directWrite=false, size=165, isUncountable=false, bytesToReserve=165, pendingBytes=16170
TRACE 2016-07-05 21:02:26.368 [nioEventLoopGroup-2-1] o.g.g.n.AbstractNIOAsyncQueueWriter - AsyncQueueWriter.write connection=TCPNIOConnection{localSocketAddress={/127.0.0.1:8445}, peerSocketAddress={/127.0.0.1:56185}}, record=org.glassfish.grizzly.asyncqueue.AsyncWriteQueueRecord@3d6e05dd, directWrite=false, size=165, isUncountable=false, bytesToReserve=165, pendingBytes=16335
...
当我设置maxPendingBytes=10000时，我预计当上面的日志中的pendingBytes变得大于10000时会抛出异常，但它不会发生。
此外，我尝试使用Grizzly的源代码调试服务器，并发现虽然属性值已分配到NIOConnection.maxAsyncWriteQueueSize字段，但AbstractNIOAsyncQueueWriter.canWrite(...)方法 - 该字段似乎唯一的位置使用 - 永远不会被称为。
我很茫然。我在这里错过了什么吗？