Java Netty 3.3.1.Final，DynamicChannelBuffer.java:75，无限循环，一个bug？

Question

我正在使用 Netty 3.3.1.Final 来满足我们对自定义服务器的需求。 我们的执行在无限循环中被阻塞： org.jboss.netty.buffer.DynamicChannelBuffer.ensureWritableBytes(DynamicChannelBuffer.java:75)

使用调试器进入代码将显示从初始值开始的无限循环： minNewCapacity=2147483647 新容量=256
（二进制 1111111111111111111111111111111）
(二进制 00000000000000000000000100000000)

原因是

这部分代码缺少文档，所以我无法深入分析，但我想知道这是否是一个已知问题，是否可以使用其他版本的 netty？

@Override
    public void ensureWritableBytes(int minWritableBytes) {
        if (minWritableBytes <= writableBytes()) {
            return;
        }

        int newCapacity;
        if (capacity() == 0) {
            newCapacity = 1;
        } else {
            newCapacity = capacity();
        }
        int minNewCapacity = writerIndex() + minWritableBytes;
        //INFINITE LOOP HERE
        while (newCapacity < minNewCapacity) {
            newCapacity <<= 1;
        }

        ChannelBuffer newBuffer = factory().getBuffer(order(), newCapacity);
        newBuffer.writeBytes(buffer, 0, writerIndex());
        buffer = newBuffer;
    }

感谢您的帮助，

雷诺

---

添加评论：

这是导致 minNewCapacity 如此之高的方法，这似乎不太好，因为它会导致巨大的内存缓冲区...... org.jboss.netty.ReplayingDecoderBuffer.readableBytes(ReplayingDecoderBuffer.java:301)

public int readableBytes() {
        if (terminated) {
            return buffer.readableBytes();
        } else {
            return Integer.MAX_VALUE - buffer.readerIndex();
        }
    }

---

添加评论 2012/04/13

我最终决定不使用 ReplayingDecoder，因为它会导致一些非常奇怪的行为。 特别是，在 decode() 方法中使用 ChannelBuffer 参数的 mark() 和 reset() 方法似乎是不安全的。 当我尝试使用 buffer.slice() 将 ChannelBuffer 包装在“私有”容器中时，我遇到了一个异常，例如“Slice 不是可重放的方法......”。 不是很复杂，扩展一个FrameDecoder，重新实现checkpoints逻辑……

Answer 1

它已成为 netty API 中的官方错误，并且已经修补。 Tiket here。 感谢 Netty 的社区！