We are currently have a rsocket use case that we are requesting with both metadata and data. Hence our metdata and data bytebuf is processed by DataAndMetadataFlyweight through rsocket-core.
We just noticed that rsocket server side received message with data overriding metadata section. We traced the issue to class Tuple3ByteBuf
|
System.arraycopy(oneBuffer, 0, results, 0, oneBuffer.length); |
|
System.arraycopy(twoBuffer, 0, results, oneBuffer.length, twoBuffer.length); |
|
System.arraycopy(threeBuffer, 0, results, twoBuffer.length, threeBuffer.length); |
In our case, the length of oneBuffer, twoBuffer and threeBuffer is 1. Furthermore our twoBuffer (metadata) and threeBuffer(data) are with type UnpooledSlicedByteBuf
Line 147 copies to the same location as line 146.
In our case, the fix should be in line 147 with
System.arraycopy(threeBuffer, 0, results, oneBuffer.length + twoBuffer.length, threeBuffer.length);
I haven't gone through all the use cases for class Tuple3ByteBuf . Could you please verify and advise how to address our issue?
We are currently have a rsocket use case that we are requesting with both metadata and data. Hence our metdata and data bytebuf is processed by
DataAndMetadataFlyweightthroughrsocket-core.We just noticed that rsocket server side received message with data overriding metadata section. We traced the issue to class
Tuple3ByteBufrsocket-java/rsocket-core/src/main/java/io/rsocket/buffer/Tuple3ByteBuf.java
Lines 145 to 147 in fa5f179
In our case, the length of oneBuffer, twoBuffer and threeBuffer is 1. Furthermore our twoBuffer (metadata) and threeBuffer(data) are with type
UnpooledSlicedByteBufLine 147 copies to the same location as line 146.
In our case, the fix should be in line 147 with
I haven't gone through all the use cases for class
Tuple3ByteBuf. Could you please verify and advise how to address our issue?