ARTEMIS-6119 Stomp subscriber cannot receive compressed messages#6522
Conversation
AntonRoskvist
force-pushed
the
ARTEMIS-6119
branch
from
2d472cf to
7c797ac
Compare
|
|
||
| @Test | ||
| public void testReceiveCompressedMessage() throws Exception { | ||
| String DATA = RandomUtil.randomAlphaNumericString(1024 * 1024); |
There was a problem hiding this comment.
this little detail here was great.. the test generated a unique string that's not very compressed. I tried using a simple "LARGE".repeat(200 * 1024) and the large message file was not there.. and I figured it out you used this to make sure it was kept as a file.. nice test!
There was a problem hiding this comment.
Thanks, yes I originally had the test produce two messages, one with the current string and the other just doing String DATA2 = "a".repeat(1024 * 1024); to test both branches in the VersionedStompFrameHandler.
I removed the second one when I realized I could just remove the populateFrameBodyFromLargeMessage method all together. Keeping the one as a large message on the broker made the most sense
2 participants
If a Stomp subscriber tries to receive a message that has been compressed by a Core client it will fail (because no inflation of the compressed body takes place)
This change would use the Core message
getDataBuffer()to manage this along with handling of "regular" large messages in theVersionedStompFrameHandler(basically moving the Large body read step from there to use the existing one on the Core message)All tests pass, though I have limited experience with the Stomp protocol so if anything seems off just let me know