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 <[email protected]> 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
