For variable-length fields SBE forces the client to copy data to its own buffer

[kdoherty2]

An example generated stub MessageRejectedDecoder

provides only

public int getOriginalMessage(final MutableDirectBuffer dst, final int dstOffset, final int length)

and

public int getOriginalMessage(final byte[] dst, final int dstOffset, final int length)

It requires the client to copy data into its own buffer.

The SBE-generated stub could provide a convenient method to get a wrapped buffer view to the variable data field to prevent copying.

[vontikov]

Does it make sense to provide the getter for the private DirectBuffer?

[mjpt777]

Can you confirm the language this applies to when raising an issue?

[daabramoff]

This issue is Java-related
wrapper object (if any) should not introduce additional GC-overhead

[tmontgomery]

A wrapper object will need to be passed in to use. Something like the following.

public void getOriginalMessage(final DirectBuffer bufferToWrap)

What this would do is call bufferToWrap.wrap and provide a view on the original buffer that includes just the field value so that the copy can be avoided (if desired).

[mjpt777]

This is possible to address using the existing API. For example:

final int length = msg.getOriginalMessageHeaderLength();
final DirectBuffer buffer = msg.buffer();
final int index = msg.limit() + msg.getOriginalMessageHeaderLength();

// Work with buffer from index for length

msg.limit(msg.limit() + msg.getOriginalMessageHeaderLength() + length);

[mjpt777]

A wrap method has been generated that allows a view unto the field.

final DirectBuffer wrapBuffer = new UnsafeBuffer(); // can be retained to avoid allocation.

msg.wrapOriginalMessage(wrapBuffer);

final byte firstByteOfOriginalMessageMember = wrapBuffer.getByte(0);
final int originalMessageLength = wrapBuffer.capacity();