2012-04-02 44 views
0

我使用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並重新實現檢查點邏輯......

+0

這應該作爲一個問題記錄在github https://github.com/netty/netty/issues這是很容易創建一個。 – Abe 2012-04-03 03:25:07

+0

您能否請開一個錯誤報告或更好地提供修復;) – 2012-04-04 05:46:05

+0

謝謝我會嘗試添加一張票到github。我不確定我是否已經在Netty的代碼中做得足夠深入......也許有時候! – RenaudBlue 2012-04-13 09:56:27

回答

1

它已經成爲一個官方的Bug在Netty API中已經是Patched了。 Tiket here。 感謝Netty的社區!