我使用Netty 3.3.1.Final來滿足我們對自定義服務器的需求。 我們的執行被阻塞在無限循環: org.jboss.netty.buffer.DynamicChannelBuffer.ensureWritableBytes(DynamicChannelBuffer.java:75)Java Netty 3.3.1.Final,DynamicChannelBuffer.java:75,無限循環,一個bug?
走進與debuger代碼將顯示一個無限循環開始於初始值: minNewCapacity = 2147483647 newCapacity = 256
(二進制1111111111111111111111111111111)
(二進制0000000000000000000000100000000)
原因是< < =操作者將引起newCapacity達到100000000000000000最大值0000000000000,並在下一步newCapacity將永遠變爲0。
這部分代碼缺少文檔,所以我不能深入分析,但我想知道這是否是已知問題,如果我可以使用其他版本的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並重新實現檢查點邏輯......
這應該作爲一個問題記錄在github https://github.com/netty/netty/issues這是很容易創建一個。 – Abe 2012-04-03 03:25:07
您能否請開一個錯誤報告或更好地提供修復;) – 2012-04-04 05:46:05
謝謝我會嘗試添加一張票到github。我不確定我是否已經在Netty的代碼中做得足夠深入......也許有時候! – RenaudBlue 2012-04-13 09:56:27