4 Replies Latest reply on Dec 2, 2014 8:30 AM by Yong Hao Gao

    Window flow control & STOMP

    Henry Clout Newbie

      Hi there.

       

      I'm trying to limit the delivery size to STOMP consumers to a single message at a time so that the progress of messages through HornetQ can be tracked with a QueueBrowser.  This is a result of reading this thread: Odd behavior with JMS QueueBrowser which suggests that client buffering causes messages to no longer be visible to a QueueBrowser.

       

      I understand this can be achieved for JMS consumers using the consumer-window-size property, but I haven't figured out how to do the same for STOMP consumers.

       

      This thread would suggest that the window size is hard coded to -1 for STOMP clients: Severe message loss using Stomp with "direct-deliver" enabled.  I've tried setting the tcp-send-buffer-size to a much lower value (1k, about the size of one of my messages) but still no joy.

       

      Is there any way to prevent client buffering for STOMP consumers?

       

      Thanks,

      Henry

       

      P.S.  The main reason for this is that the message processing is expensive, it can take several minutes, so providing feedback to a client as to how their messages are progressing is desirable.

        • 1. Re: Window flow control & STOMP
          Yong Hao Gao Master

          HornetQ stomp doesn't support such a feature. In fact you may not need it. What type of client are you using? java or perl or .net?  Why not your client just receive one message after your finished the previous one?

           

          Howard

          • 2. Re: Re: Window flow control & STOMP
            Henry Clout Newbie

            Thanks for this Howard.

             

            I'm using Net::STOMP::Client in Perl, using a STOMP 1.2 connection.  I've looked through the docs for the client library, but can't see anything regarding limiting the buffer size.

             

            I've taken a Wireshark capture of the comms between HornetQ and the Perl client :

             

            CONNECT

            heart-beat:30000,0

            accept-version:1.0,1.1,1.2

            host:localhost

             

             

            .CONNECTED

            version:1.2

            session:-703037976

            server:HornetQ/2.5.0.SNAPSHOT (Wild Hornet, 124) HornetQ Messaging Engine

            heart-beat:0,30000

             

             

            .

            SUBSCRIBE

            ack:client-individual

            id:job-processor-unix-unix1

            destination:jms.queue.transcode.request.unix.generic

             

             

            .MESSAGE

            subscription:job-processor-unix-unix1

            message-id:2278522

            destination:jms.queue.transcode.request.unix.generic

            expires:0

            redelivered:false

            priority:2

            timestamp:1417515517622

            __HQ_CID:cedb1e70-7a01-11e4-bda2-5f3ad34d5a71

            ack:2278522

            content-length:155

             

             

            messageVersion=2.0,jobGuid=73pndulyNxo,responseQueue=jms.queue.trunk.henry.kuluvalley.com.transcode.response,progressScript=./resources/ffmpeg_progress.pl

            .

            MESSAGE

            subscription:job-processor-unix-unix1

            message-id:2278518

            destination:jms.queue.transcode.request.unix.generic

            expires:0

            redelivered:false

            priority:1

            timestamp:1417515517326

            __HQ_CID:cedb1e70-7a01-11e4-bda2-5f3ad34d5a71

            ack:2278518

            content-length:155

             

             

            messageVersion=2.0,jobGuid=hRgiIG3zJVP,responseQueue=jms.queue.trunk.henry.kuluvalley.com.transcode.response,progressScript=./resources/ffmpeg_progress.pl

            .

             

            ...

             

            (there are more messages sent from HornetQ without response from the Perl client -- I didn't include these for the sake of brevity.)

             

            I've tried changing the subscribe mode to 'client' rather than 'client-individual' in case that changed the behaviour, but alas no joy.

             

            Do you know of a header or some such I could set in the connect / subscribe on the Perl side that would cause HornetQ to send a single message at a time?

             

            Thanks,

            Henry

            • 3. Re: Re: Window flow control & STOMP
              Henry Clout Newbie

              I've got a work around, although you'd hardly accuse it of being elegant.

               

              Adding 32k of padding to the messages sent to the STOMP client causes a single message to be sent at a time.  This is with the parameter <param key="tcp-send-buffer-size" value="1024"/> set or with it absent (thus defaulting to 32k according to the docs) on the STOMP acceptor.

               

              This solves the problem for me, but if there is a cleaner solution this would clearly be preferable.

              • 4. Re: Re: Window flow control & STOMP
                Yong Hao Gao Master

                No unfortunately there isn't such a header.