[grepjava]

The STOMP 1.1 and 1.2 decoders (StompDecoderV11.parseBody and its copy in StompDecoderV12), given a content-length, took the frame once the buffer held the body and one more byte, then skipped ahead to the NUL. When bytes followed the body before the NUL and the buffer ended before that NUL, the frame was returned anyway, and the rest of it, arriving in the next packet, was parsed as the next frame's command: the client got AMQ339023 Invalid STOMP frame. In one packet the same bytes were accepted, so whether such a frame went through depended on how TCP split it.

Both decoders now look for the NUL first and wait for more bytes until it is there, as they already do for a frame without content-length.

StompV11Test and StompV12Test.testFrameEndingInALaterPacketThanItsContentLengthBody send a frame with content-length:5 and the body plus one byte, then the rest up to the NUL in a second write, then another frame, and check both receipts and both messages. They fail without the fix.

https://issues.apache.org/jira/browse/ARTEMIS-6359