Java Netty 3.3.1.Final, DynamicChannelBuffer.java:75, бесконечный цикл, ошибка? - PullRequest
Новая
       4

Java Netty 3.3.1.Final, DynamicChannelBuffer.java:75, бесконечный цикл, ошибка?

0 голосов
/ 02 апреля 2012

Я использую Netty 3.3.1.Final для наших нужд на пользовательском сервере. Наше выполнение заблокировано в бесконечном цикле в: org.jboss.netty.buffer.DynamicChannelBuffer.ensureWritableBytes (DynamicChannelBuffer.java:75)

Переход в код с отладчиком покажет бесконечный цикл, начинающийся с начальных значений: minNewCapacity = 2147483647 newCapacity = 256
(Бинарный 1111111111111111111111111111111)
(Двоичный 0000000000000000000000100000000)

Причина в том, что << = оператор приведет к тому, что newCapacity достигнет максимального значения 1000000000000000000000000000000, а на следующем шаге newCapacity станет 0 навсегда. </p>

В этой части кода отсутствует документация, поэтому я не могу углубляться в анализ, но я хотел бы знать, является ли это известной проблемой, и могу ли я использовать другую версию 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;
    }

Спасибо за вашу помощь,

Renaud

Добавлен комментарий:

Это метод, заставляющий 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, потому что это ведет к очень странному поведению. В частности, похоже, что небезопасно использовать методы mark () и reset () аргумента ChannelBuffer в методе decode (). Когда я попытался использовать buffer.slice (), чтобы обернуть ChannelBuffer в «закрытый» контейнер, я получил исключение, что-то вроде «Slice - не воспроизводимый метод ...». Это не очень сложно, то есть расширить FrameDecoder и заново реализовать логику контрольных точек ...

1 Ответ

1 голос
/ 16 апреля 2012

Это стало официальной ошибкой в ​​netty API с уже исправленным патчем. Тикет здесь . Спасибо сообществу Нетти!

...