QPIDJMS-417 Reduce GC pressure while using BytesMessage

[franz1981]

Using directly ByteBuf-based streams allows to avoid unnecessary creations of intermediate instances to operate on the underline ByteBuf content

[franz1981]

@gemmellr @tabish121 I'm not very proud to have exposed directly the ByteBuf streams, but I have tried to use the right type on the facade and it makes the code really unreadable (and confuse the mocking framework too!!) :(

<I extends InputStream & DataInput> I getInputStream() throws JMSException;

[gemmellr]

Can you elaborate on the benefits you measured here? I'd like to understand the extent to consider against the downside of exposing dep impl types throughout the code base.

The existing bits worked the way it did at least a small part because BytesMessage specified thats where it gets its behaviours from. Are we sure ByteBuf streams behave the same?

[franz1981]

@gemmellr

Can you elaborate on the benefits you measured here? I'd like to understand the extent to consider against the downside of exposing dep impl types throughout the code base.

Fair enough :+1: I will come up with a test to measure the reduction of GC (with 100 bytes message)

The existing bits worked the way it did at least a small part because BytesMessage specified thats where it gets its behaviours from. Are we sure ByteBuf streams behave the same?

Looking at the tests on Netty (where I have put recently a PR re some of these classes) it seems the case, but it is not part of Java util classes so they could be wrong on it. Do we have some tests to verify the impact on the client of it?