Problem with the ByteOrder

[Matthias Wimmer]

Hi!


I am reading 16 bit values from a Buffer I get passed to a class that
extends AbstractTransformer<Buffer, GWMessage>. (GWMessage is a class
of mine.)

The protocol I am reading is binary over UDP and uses little endian
encoding. Therefore the first thing I do in .transformImpl(…) is to call
.order(ByteOrder.LITTLE_ENDIAN) on the Buffer I get.

Afterwards I am calling .getShort() on the Buffer. Sometimes I get the
result I am expecting, sometimes I get the wrong data.

Example:
The data the Buffer starts with might be: 50 49 4E 47
When I call .getShort() on it sometimes I get 0x4950 (correct) but
sometimes I get 0x5049 instead (bytes in incorrect order).

I have checked the actual class implementing the Buffer I get. It's
BuffersBuffer. If I understand this class right, the call of
.order(ByteOrder.LITTLE_ENDIAN) will set byteOrder to LITTLE_ENDIAN and
bigEndian to false.

The call to .getShort() will call .getShort(position) which will call
activeBuffer.getShort(other_position).

activeBuffer is the underlaying buffer, that is wrapped by
BuffersBuffer, right? If this activeBuffer has a different byte order
than my instance of BuffersBuffer I will get the data in the wrong byte
order. I don't see where the changed byte order would be respected.

Am I just doing something, that is not allowed to do? Or is this a bug
in the implementation of Grizzly?


Regards,
Matthias


Some more information about what I am doing:

- I am reading UDP packets from the network.

- The code I am using looks like this. (Sure, there are more methods I
  had to implement:



public class ScomboxDecoder extends AbstractTransformer<Buffer, GWMessage> {


    protected TransformationResult<Buffer, GWMessage> transformImpl(
        final AttributeStorage storage, final Buffer input)
        throws TransformationException {

        input.order(ByteOrder.LITTLE_ENDIAN);
        final short firstTwoBytes = input.getShort();

        System.out.format("%04x\n", firstTwoBytes & 0xFFFF);

        […]
    }
}



--
Matthias Wimmer
Contact details:     http://matthias.wimmer.tel/

[oleksiys]

Hi,

you're absolutely right, it's a bug.
Please file an issue, we'll fix it asap.

Thank you.

WBR,
Alexey.

On 14.08.14 09:34, Matthias Wimmer wrote:

> Hi!
>
>
> I am reading 16 bit values from a Buffer I get passed to a class that
> extends AbstractTransformer<Buffer, GWMessage>. (GWMessage is a class
> of mine.)
>
> The protocol I am reading is binary over UDP and uses little endian
> encoding. Therefore the first thing I do in .transformImpl(…) is to call
> .order(ByteOrder.LITTLE_ENDIAN) on the Buffer I get.
>
> Afterwards I am calling .getShort() on the Buffer. Sometimes I get the
> result I am expecting, sometimes I get the wrong data.
>
> Example:
> The data the Buffer starts with might be: 50 49 4E 47
> When I call .getShort() on it sometimes I get 0x4950 (correct) but
> sometimes I get 0x5049 instead (bytes in incorrect order).
>
> I have checked the actual class implementing the Buffer I get. It's
> BuffersBuffer. If I understand this class right, the call of
> .order(ByteOrder.LITTLE_ENDIAN) will set byteOrder to LITTLE_ENDIAN and
> bigEndian to false.
>
> The call to .getShort() will call .getShort(position) which will call
> activeBuffer.getShort(other_position).
>
> activeBuffer is the underlaying buffer, that is wrapped by
> BuffersBuffer, right? If this activeBuffer has a different byte order
> than my instance of BuffersBuffer I will get the data in the wrong byte
> order. I don't see where the changed byte order would be respected.
>
> Am I just doing something, that is not allowed to do? Or is this a bug
> in the implementation of Grizzly?
>
>
> Regards,
> Matthias
>
>
> Some more information about what I am doing:
>
> - I am reading UDP packets from the network.
>
> - The code I am using looks like this. (Sure, there are more methods I
>    had to implement:
>
>
>
> public class ScomboxDecoder extends AbstractTransformer<Buffer, GWMessage> {
>
>
>      protected TransformationResult<Buffer, GWMessage> transformImpl(
>          final AttributeStorage storage, final Buffer input)
> throws TransformationException {
>
> input.order(ByteOrder.LITTLE_ENDIAN);
> final short firstTwoBytes = input.getShort();
>
> System.out.format("%04x\n", firstTwoBytes & 0xFFFF);
>
> […]
>      }
> }
>
>
>

[Matthias Wimmer]

Hi Alexey,

El 2014-08-14 10:46:41, Oleksiy Stashok escribió:
> you're absolutely right, it's a bug.
> Please file an issue, we'll fix it asap.

Thanks for the fast reply. The bug has been filed :-)


Regards,
Matthias


--
Matthias Wimmer
Contact details:     http://matthias.wimmer.tel/

[oleksiys]

Hi Matthias,

can you pls. check if the latest 2.3.17-SNAPSHOT fixes the issue?

Thank you!

WBR,
Alexey.

On 15.08.14 00:21, Matthias Wimmer wrote:

> Hi Alexey,
>
> El 2014-08-14 10:46:41, Oleksiy Stashok escribió:
>> you're absolutely right, it's a bug.
>> Please file an issue, we'll fix it asap.
> Thanks for the fast reply. The bug has been filed :-)
>
>
> Regards,
> Matthias
>
>

[Matthias Wimmer]

El 2014-08-19 17:15:03, Oleksiy Stashok escribió:
> can you pls. check if the latest 2.3.17-SNAPSHOT fixes the issue?
>
> Thank you!

Where can I get this from?


Regards,
Matthias

--
Matthias Wimmer
Contact details:     http://matthias.wimmer.tel/

[Pavel Bucek]

On 20/08/14 10:36, Matthias Wimmer wrote:

> El 2014-08-19 17:15:03, Oleksiy Stashok escribió:
>> can you pls. check if the latest 2.3.17-SNAPSHOT fixes the issue?
>>
>> Thank you!
> Where can I get this from?
>
>
> Regards,
> Matthias
>

https://maven.java.net/content/repositories/snapshots/ 
(org/glassfish/grizzly/..)