ByteBuf supports “marker indexes”. The intended use case for these is if a speculative operation (e.g. decode) is in process the user can “mark” and interface and refer to it later if the operation isn’t successful (e.g. not enough data). However this is rarely used in practice,
requires extra memory to maintain, and introduces complexity in the state management for derived/pooled buffer initialization, resizing, and other operations which may modify reader/writer indexes.
We should drop the support of marking indices.
@normanmaurer so if you had some code like this that reads ahead when decoding
case READ_SENDER_IP:
if (buffer.readableBytes() < BYTE_SIZE) {
return;
}
buffer.markReaderIndex();
int octetsLength = buffer.readByte();
if (buffer.readableBytes() < octetsLength) {
buffer.resetReaderIndex();
return;
}
byte[] octets = new byte[octetsLength];
buffer.readBytes(octets);
senderIp = InetAddress.getByAddress(octets);
I guess one could do something like this..
case READ_SENDER_IP:
if (buffer.readableBytes() < BYTE_SIZE) {
return;
}
//buffer.markReaderIndex();
int octetsLength = buffer.getByte(buffer.readerIndex()); // get instead of read to avoid moving the reader index
if (buffer.readableBytes() < octetsLength) {
//buffer.resetReaderIndex();
return;
}
byte[] octets = new byte[octetsLength];
buffer.readBytes(octets);
senderIp = InetAddress.getByAddress(octets);
currentState = DecoderState.READ_SENDER_PORT;
@johnou yes or just store the original readerIndex and set it again if needed.
Worst-case here would could have an API that returns a "mark object" (with the saved index) that could then be "restored". But doing it manually is likely okay.
Most helpful comment
@johnou yes or just store the original readerIndex and set it again if needed.