I think I've found a somewhat serious bug in the STOMP adapter: after a burst of incoming messages, the last one remains buffered somewhere indefinitely and is not added to the queue until another message is received from the same connection (same with topics). This cause and excessive delay to deliver the message to consumers, if it is ever delivered. Besides that, that last message is lost if the connection is not properly closed.<br><br>I've attached a simple script which replicates the bug. It sends burst of 100 small messages to a queue every 10 seconds. Using the management console, we can inspect the count of Ready messages. The expected progression is 100 ... 200 ... 300 ... 400 ... 500, but very frequently (not always) we get 99 ... 199 ... 299 ... 399 ... 499, as the last message is not queued.<br><br>Could be that the STOMP parser gets confused after an incomplete frame was read from tcp buffer? Any ideas?<br><br>Regards,<br>José<br>