[nms-amqp] NmsBytesMessage Content getter has side effects

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[nms-amqp] NmsBytesMessage Content getter has side effects

Krzysztof
Hi,

Recently on nms-amqp bug tracker the following issue was raised

https://issues.apache.org/jira/browse/AMQNET-625

I've confirmed that the described behavior actually takes place, and may be
quite annoying especially if one is debugging the code and try to inspect
the content of the bytes message (as c# properties are automatically
evaluated when you try to inspect an object using watch window) the message
is corrupted. There is no way to read its content ever again unless we
reset the underlying stream.

I've confirmed that this behavior is in line with qpid-jms implementation
(at least ReadBytes() method we are invoking in Content getter behaves in
the same way). But my question is, is this really desired or described
somewhere in jms spec? As java JMS implementation of BytesMessage doesn't
have a Content getter it shouldn't be a case.

I know that with the underlying provider (at least in nms-amqp and
AmqpNetLite) we could support multiple reads quite easily if we decouple
the Content getter from the state of the stream that's manipulated by all
Read* methods.

What do you think?

Regards,
Krzysztof Porebski
Reply | Threaded
Open this post in threaded view
|

Re: [nms-amqp] NmsBytesMessage Content getter has side effects

Robbie Gemmell
I dont believe Qpid JMS has a comparable behaviour. The getBody()
method (added in JMS2) copies the underlying payload to a fresh array,
the various read<Foo> style accessors operate on a different input
stream. There isnt a similar 'get content' property with side effects
behaviour that I see. You can get the entire content, or read content
from the message byte stream in various ways and reset the message if
you want to read any earlier content with them again.

Robbie

On Sat, 2 Nov 2019 at 21:42, Krzysztof <[hidden email]> wrote:

>
> Hi,
>
> Recently on nms-amqp bug tracker the following issue was raised
>
> https://issues.apache.org/jira/browse/AMQNET-625
>
> I've confirmed that the described behavior actually takes place, and may be
> quite annoying especially if one is debugging the code and try to inspect
> the content of the bytes message (as c# properties are automatically
> evaluated when you try to inspect an object using watch window) the message
> is corrupted. There is no way to read its content ever again unless we
> reset the underlying stream.
>
> I've confirmed that this behavior is in line with qpid-jms implementation
> (at least ReadBytes() method we are invoking in Content getter behaves in
> the same way). But my question is, is this really desired or described
> somewhere in jms spec? As java JMS implementation of BytesMessage doesn't
> have a Content getter it shouldn't be a case.
>
> I know that with the underlying provider (at least in nms-amqp and
> AmqpNetLite) we could support multiple reads quite easily if we decouple
> the Content getter from the state of the stream that's manipulated by all
> Read* methods.
>
> What do you think?
>
> Regards,
> Krzysztof Porebski
Reply | Threaded
Open this post in threaded view
|

Re: [nms-amqp] NmsBytesMessage Content getter has side effects

Krzysztof
Hi Robbie,

Do you mean this? -->
https://github.com/apache/qpid-jms/blob/0af503a9bb7af3c7e25e1a16c42ab0b30919a5a8/qpid-jms-client/src/main/java/org/apache/qpid/jms/message/JmsBytesMessage.java#L412-L420

On Mon, Nov 4, 2019 at 11:31 AM Robbie Gemmell <[hidden email]>
wrote:

> I dont believe Qpid JMS has a comparable behaviour. The getBody()
> method (added in JMS2) copies the underlying payload to a fresh array,
> the various read<Foo> style accessors operate on a different input
> stream. There isnt a similar 'get content' property with side effects
> behaviour that I see. You can get the entire content, or read content
> from the message byte stream in various ways and reset the message if
> you want to read any earlier content with them again.
>
> Robbie
>
> On Sat, 2 Nov 2019 at 21:42, Krzysztof <[hidden email]> wrote:
> >
> > Hi,
> >
> > Recently on nms-amqp bug tracker the following issue was raised
> >
> > https://issues.apache.org/jira/browse/AMQNET-625
> >
> > I've confirmed that the described behavior actually takes place, and may
> be
> > quite annoying especially if one is debugging the code and try to inspect
> > the content of the bytes message (as c# properties are automatically
> > evaluated when you try to inspect an object using watch window) the
> message
> > is corrupted. There is no way to read its content ever again unless we
> > reset the underlying stream.
> >
> > I've confirmed that this behavior is in line with qpid-jms implementation
> > (at least ReadBytes() method we are invoking in Content getter behaves in
> > the same way). But my question is, is this really desired or described
> > somewhere in jms spec? As java JMS implementation of BytesMessage doesn't
> > have a Content getter it shouldn't be a case.
> >
> > I know that with the underlying provider (at least in nms-amqp and
> > AmqpNetLite) we could support multiple reads quite easily if we decouple
> > the Content getter from the state of the stream that's manipulated by all
> > Read* methods.
> >
> > What do you think?
> >
> > Regards,
> > Krzysztof Porebski
>
Reply | Threaded
Open this post in threaded view
|

Re: [nms-amqp] NmsBytesMessage Content getter has side effects

Robbie Gemmell
I wasnt looking there (I was further down in the client) but its
highly related, yes. On consideration of that method, the JMS
Message.getBody(<class>) method can indeed have a side effect, but a
fairly narrow one, and one which is required by JMS:
"This method will reset the BytesMessage before and after use."

So getBody might cause observable side effect upon use if the
read<Foo> methods have been used in certain ways before it was called
and are then used again subsequently afterwards, in that the message
will be at the start of the byte stream even if it wasnt already to
begin with. It still doesnt seem like it behaves as the NMS bits are
described to though.

Robbie

On Mon, 4 Nov 2019 at 12:47, Krzysztof <[hidden email]> wrote:

>
> Hi Robbie,
>
> Do you mean this? -->
> https://github.com/apache/qpid-jms/blob/0af503a9bb7af3c7e25e1a16c42ab0b30919a5a8/qpid-jms-client/src/main/java/org/apache/qpid/jms/message/JmsBytesMessage.java#L412-L420
>
> On Mon, Nov 4, 2019 at 11:31 AM Robbie Gemmell <[hidden email]>
> wrote:
>
> > I dont believe Qpid JMS has a comparable behaviour. The getBody()
> > method (added in JMS2) copies the underlying payload to a fresh array,
> > the various read<Foo> style accessors operate on a different input
> > stream. There isnt a similar 'get content' property with side effects
> > behaviour that I see. You can get the entire content, or read content
> > from the message byte stream in various ways and reset the message if
> > you want to read any earlier content with them again.
> >
> > Robbie
> >
> > On Sat, 2 Nov 2019 at 21:42, Krzysztof <[hidden email]> wrote:
> > >
> > > Hi,
> > >
> > > Recently on nms-amqp bug tracker the following issue was raised
> > >
> > > https://issues.apache.org/jira/browse/AMQNET-625
> > >
> > > I've confirmed that the described behavior actually takes place, and may
> > be
> > > quite annoying especially if one is debugging the code and try to inspect
> > > the content of the bytes message (as c# properties are automatically
> > > evaluated when you try to inspect an object using watch window) the
> > message
> > > is corrupted. There is no way to read its content ever again unless we
> > > reset the underlying stream.
> > >
> > > I've confirmed that this behavior is in line with qpid-jms implementation
> > > (at least ReadBytes() method we are invoking in Content getter behaves in
> > > the same way). But my question is, is this really desired or described
> > > somewhere in jms spec? As java JMS implementation of BytesMessage doesn't
> > > have a Content getter it shouldn't be a case.
> > >
> > > I know that with the underlying provider (at least in nms-amqp and
> > > AmqpNetLite) we could support multiple reads quite easily if we decouple
> > > the Content getter from the state of the stream that's manipulated by all
> > > Read* methods.
> > >
> > > What do you think?
> > >
> > > Regards,
> > > Krzysztof Porebski
> >