I'm including one more failing tests: @Test public void encodeAndDecodeMediumSizeStringOfMoreThan26Chars() { String string = "60v4MKNelDuNDUHn8itGjok2HN0"; ActiveMQBuffer pooledBuffer = ActiveMQBuffers.pooledBuffer(21); pooledBuffer.writeString(string);
var array = pooledBuffer.toByteBuffer().array(); ActiveMQBuffer activeMQBuffer = ActiveMQBuffers.wrappedBuffer(array); String decoded = activeMQBuffer.readString(); Assert.assertEquals(string, decoded); } org.junit.ComparisonFailure: Expected :60v4MKNelDuNDUHn8itGjok2HN0 Actual :��������������������������� On Sun, Mar 3, 2024 at 12:44 AM Havret <hav...@apache.org> wrote: > Hi, > > I've recently started working on the dotnet Artemis Client that's going to > use Core protocol. During my work on the binary encoder, I've hit a weird > issue. Everything works fine when I encode strings up to 26 characters. > But, for strings longer than 26 characters, the binary layout just goes > haywire—there's this huge 8k bytes gap from where the last data was > encoded, and I can't figure out why. > > I managed to boil it down to 2 simple test cases you can find here: > https://gist.github.com/Havret/486a5acc339c67cdc11eccc33e54b178. The > unpooledBuffer behaves as expected, just like in my dotnet setup, but the > pooledBuffer acts up strangely. Is this some bug in the Artemis core > encoding, or am I missing something obvious? > > Thanks for any light you can shed on this, > Krzysztof > > >