4 Replies Latest reply on May 22, 2013 9:12 AM by Yong Hao Gao

    Size Limits on Stomp

    Yong Hao Gao Master

      The main concern without size limit is that if the message size is over the min-large-message-size HornetQ will

      split the message into trunks and deliver it as large messages, which STOMP protocol doesn't support.

       

      We could implement the 'Size Limits' feature as in the STOMP protocol to solve the problem. But it's not enough

      because it only limits the sender's capability. We still need to think of a way to prevent large messages from

      being delivered to STOMP clients.

       

      One option is to send an ERROR message to the client on the first occurrence of large messages and disconnect.

      The client will know that there are some large messges there and maybe adjust the limits and receive again.

       

      If anyone has more options please let me know.

       

       

      Extract from STOMP protocol spec (1.1 and above):

       

      Size Limits

       

      To prevent malicious clients from exploiting memory allocation in a server, servers MAY place maximum limits on:

      the number of frame headers allowed in a single frame

      the maximum length of header lines

      the maximum size of a frame body

      If these limits are exceeded the server SHOULD send the client an ERROR frame and then close the connection.

        • 1. Re: Size Limits on Stomp
          Clebert Suconic Master

          I see no difference with the regular protocol. If you add a size limit on Stomp you ought to add it on core as well...

           

          You would have to make it consistent. Feel free to add a JIRA with a feature request on 2.4 if you like, but then it would be on master only and it would be applied for both core/regular messages and stomp messages.

           

           

          for now, all we need is to have minLargeMessageSize. If a message > minLargeMessage after parsin on the server, then we would convert it to a ServerLargeMessage and store it accordingly.

           

           

          Same deal when receiving a message... it would be read into a ByteBuffer and sent to the client. We would off course document the behaviour and the user would have to be aware of that.

           

           

          for next version we can implement a limit and parse it accordingly. But that would be a different feature.

          • 2. Re: Size Limits on Stomp
            Yong Hao Gao Master

            Clebert Suconic wrote:

             

            I see no difference with the regular protocol. If you add a size limit on Stomp you ought to add it on core as well...

             

            Hi Clebert,

             

            Do you mean we add this limit for all kinds of clients? If we add this limit to the core, not only stomp clients, but also JMS clients and Core clients will be affected. Do we want to do this?

             

            Howard

            • 3. Re: Size Limits on Stomp
              Clebert Suconic Master

              Adding an upper limit is certainly a feature.. but as I said not now... you may add this as a JIRA for 2.4+ and we will decide if we want to implement or not?

              • 4. Re: Size Limits on Stomp
                Yong Hao Gao Master

                Agreed. I'll create another Jira.

                 

                Howard