ZaynJiang

我也出现了，upstraem配置总是找不到端口，删了之前的配置一致性也有问题，一直在刷新以前的配置

我的客户端目前就是cat服务端长时间呆住，我重启服务端后，客户端内存泄漏了，dump客户端，channel是active和open的，但是是不可写的入的，这个checker会一直执行导致taskqueue无限增长，怀疑nioeventloop selector run线程无法消费数据，导致buffer无法恢复至channel一直被流量控制不可写入。目前还没成功再次模拟出现这种场景了，如图，应用进程无法fullgc的时候，这个taskqueue对象非常多  > 我倒是没有碰到过这种情况。有时也会出现 CAT 服务端机器长时间呆住，但是并没有收到客户端内存泄露的报告。不知道你能不能顺便测试一下这个场景，可以在 debug 状态下，让服务端保持连接但不处理消息，看看客户端不断发消息后，内存的泄露情况。 > […](#)

> 如果isWritable() 是 false，多 flush 几次应该没有负面影响。task queue 中消息应该是之前的写入的，如果 isWritable() 一直返回 false，就不会有新消息写入。 > > 时间久了，忘了 isWritable() 返回 false 的原因了，不妨你去跟踪一下 netty 内部代码 > […](#) isWritable() false我看了下是netty的outboundBuffer写入数量超过了64Kb数据就会流量控制，置为false。task queue的消息全是AbstractChannelHandlerContext中的invokeFlushTask对象，这个入口就是cat中的ChannelManager的checker，确实内存异常增长是在我重启服务端之后，这个可能导致channel被激活？。我想到可能是就是selector异常了，netty只会通过selector事件去write吗，只能再研究研究netty了，现在生产应用比较多，还是有点担心以后重启cat搞出事故