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
>
>
>

Reply via email to