4 Replies Latest reply on May 22, 2013 9:12 AM by gaohoward

    Size Limits on Stomp

    gaohoward
    gaohoward May 21, 2013 10:40 PM

      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.

      • 1278 Views
      • Tags:
        • 1. Re: Size Limits on Stomp
          clebert.suconic
          clebert.suconic May 21, 2013 11:20 PM (in response to gaohoward)

          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.

            • Actions
          • 2. Re: Size Limits on Stomp
            gaohoward
            gaohoward May 22, 2013 3:51 AM (in response to clebert.suconic)

            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

              • Actions
            • 3. Re: Size Limits on Stomp
              clebert.suconic
              clebert.suconic May 22, 2013 9:09 AM (in response to gaohoward)

              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?

                • Actions
              • 4. Re: Size Limits on Stomp
                gaohoward
                gaohoward May 22, 2013 9:12 AM (in response to clebert.suconic)

                Agreed. I'll create another Jira.

                 

                Howard

                  • Actions