Sparodic OutOfBounds Problem mit Netty 4.01 CR6

Question

Ich habe ein Problem mit einem benutzerdefinierten Decoder, den ich entwickelt habe und bin mir nicht sicher, was ich falsch mache.

Das Nachrichtenformat, das wir erhalten, enthält HEADER, BODY und TRAILER. Der Header ist 1 Byte und ist ein STX (0x02) Der Rumpf hat variable Länge Der Trailer ist 2 Bytes, die ein ETX (0x03) gefolgt von einem LRC enthalten.

So eine typische Nachricht könnte wie folgt aussehen:

STX BODY ETX LRC 
02 37000000 06 18 

Der Ausgang des Decoders soll die Nachricht ohne den STX Control-Byte sein. So ist die Nachricht auf gesendet wird, ist:

BODY  ETX LRC 
37000000 06 18 

Wir haben die DelimiterBasedFrameDecoder erweitert und definiert das ETX als Trennzeichen. Die Absicht des Decoders besteht darin, das nächste Byte zu lesen, es dem Puffer hinzuzufügen und es dann zu senden, auf diese Weise senden wir eine vollständige Nachricht. Unsere Dekodiermethode sieht so aus:

Alles funktioniert wie erwartet, außer dass wir regelmäßig die folgende Ausnahme erhalten.

java.lang.IndexOutOfBoundsException: readerIndex(225) + length(1) exceeds writerIndex(225): UnpooledUnsafeDirectByteBuf(ridx: 225, widx: 225, cap: 256) 

Wir verwenden netty 4.01 CR6 und es ist ein sporadisches Problem. Worüber ich mir nicht sicher bin, ist das, was ich nicht richtig mache, oder ist es ein Thema, das in Netty liegt. Da ich Netty ziemlich neu bin, vermute ich, dass es etwas ist, was ich tue, aber ich bin mir nicht sicher.

Ich hoffe, dass jemand mir helfen kann, dies zu lösen. Ich bin mehr als glücklich, weitere Informationen zu posten, um das gelöst zu bekommen, einfach fragen.

Schätzen Sie jede und alle Hilfe, die ich auf diesem einen bekommen kann.

• Tim

Answer 1

Diese Ausnahme bedeutet, dass Sie einen Byte aus dem bytebuf zu lesen versuchen, dass es nicht enthält, weil Sie das Ende davon erreicht.

Entweder der Client hat ungültige Daten gesendet, oder nicht alle Pakete in Ihrem Protokoll haben die STX in der Nachricht.

Ein weiterer Fehler, der bei der Decodierung eines bereits vorhandenen Protokolls häufig auftritt, besteht darin, dass die Bytefolge, die Sie als Trennzeichen verwenden, in den Paketen selbst verwendet wird und die Pakete Byte für Byte gelesen werden.

Wenn Sie die Pakete sehen wollen, die zu Ihrem Decoder fließen, können Sie der Pipeline kurz vor dem Dekodieren einen LoggingHandler(LogLevel.INFO) hinzufügen, so dass die rohen Bytes als Hex ausgegeben werden, so dass Sie überprüfen können, ob dies der Fall ist enthält tatsächlich die benötigten Bytefolgen.

Sidenote: Sie geben niemals das in msg gespeicherte Bytebuf frei. Dies führt zu Speicherlecks und führt schließlich zu einem OOM. Stellen Sie sicher, dass die Freigabe in einem try-finally-Block aufgerufen wird, so dass dieser immer

heißt