6 Replies Latest reply on Dec 26, 2012 11:14 PM by Yong Hao Gao

    reliable message sends using STOMP

    Sam Bishop Newbie

      I have a question about how to use STOMP with HornetQ.  We have been using HornetQ for a long time, but only as a JMS broker.  Now we have an external system that we would like to receive messages from, and that system is written in Perl.  The obvious thing to do was to enable a STOMP acceptor in our broker configuration.  I did that and found that successfully sending messages from Perl was a snap, and I thought all was well.


      However, I then checked to make sure that a send fails when I would expect it to, so I tried sending to an non-existent address.  What I found was that the Perl client seems unaware that something went wrong, there is no complaint in the HornetQ logs, and I see no sign of the message on the server.  This is a big problem for us, since we want to be absolutely sure that we do not lose these messages.


      We are using the Net::Stomp Perl library, version 0.45, and HornetQ version 2.2.5.  We are also using the send_transactional Net::Stomp method, which uses BEGIN, RECEIPT, and COMMIT frames to make sure that the server has successfully received the message.


      I'm still trying different things to figure out how to make this work, but I thought I would ask to see if someone else has dealt with this before.




        • 1. Re: reliable message sends using STOMP
          Yong Hao Gao Master

          2.2.5 is a pretty old version. Can you please try the latest release?

          • 2. Re: reliable message sends using STOMP
            Sam Bishop Newbie

            Sure.  I've reproduced this using the 2.3.0.BETA3 release.  At this point I believe this is a bug.  Let me know if I ought to enter a JIRA case.


            Besides bumping up the HornetQ version, I have also switched to a Perl library that has good debugging support.  Here's my Perl code:




            use Net::STOMP::Client;

            use No::Worries::Log qw(*);



            $Net::STOMP::Client::Debug = "all";


            my $stomp = Net::STOMP::Client->new(host => 'localhost', port => '61613');


            my $ret = $stomp->send(

                    destination => 'jms.queue.NonExistent',

                    body => 'message body',

                    receipt => $stomp->uuid()


            $stomp->wait_for_receipts(timeout => 10);



            And here's the output:


            # 2012/12/21-09:16:04 titan-stomp2[6832]: connect to tcp://localhost:61613 ok:

            # 2012/12/21-09:16:04 titan-stomp2[6832]: Net::STOMP::Client=HASH(0x803c7ee8)->connect()

            # 2012/12/21-09:16:04 titan-stomp2[6832]: encoding CONNECT frame

            # 2012/12/21-09:16:04 titan-stomp2[6832]:  H accept-version:1.0,1.1,1.2

            # 2012/12/21-09:16:04 titan-stomp2[6832]:  H host:localhost

            # 2012/12/21-09:16:04 titan-stomp2[6832]: sent 52 bytes

            # 2012/12/21-09:16:04 titan-stomp2[6832]: received 89 bytes

            # 2012/12/21-09:16:04 titan-stomp2[6832]: decoding CONNECTED frame

            # 2012/12/21-09:16:04 titan-stomp2[6832]:  H version:1.1

            # 2012/12/21-09:16:04 titan-stomp2[6832]:  H session:945282069

            # 2012/12/21-09:16:04 titan-stomp2[6832]:  H server:HornetQ/2.2.5 HornetQ Messaging Engine

            # 2012/12/21-09:16:04 titan-stomp2[6832]: Net::STOMP::Client=HASH(0x803c7ee8)->send()

            # 2012/12/21-09:16:04 titan-stomp2[6832]: encoding SEND frame

            # 2012/12/21-09:16:04 titan-stomp2[6832]:  H destination:jms.queue.NonExistent

            # 2012/12/21-09:16:04 titan-stomp2[6832]:  H receipt:803c7ee8-50d48b44-1ab0-c96f-1

            # 2012/12/21-09:16:04 titan-stomp2[6832]:  H content-length:12

            # 2012/12/21-09:16:04 titan-stomp2[6832]:  B 0000 6d657373 61676520 626f6479           mess age  body

            # 2012/12/21-09:16:04 titan-stomp2[6832]: sent 109 bytes

            # 2012/12/21-09:16:04 titan-stomp2[6832]: received 52 bytes

            # 2012/12/21-09:16:04 titan-stomp2[6832]: decoding RECEIPT frame

            # 2012/12/21-09:16:04 titan-stomp2[6832]:  H receipt-id:803c7ee8-50d48b44-1ab0-c96f-1

            # 2012/12/21-09:16:04 titan-stomp2[6832]: Net::STOMP::Client=HASH(0x803c7ee8)->disconnect()

            # 2012/12/21-09:16:04 titan-stomp2[6832]: encoding DISCONNECT frame

            # 2012/12/21-09:16:04 titan-stomp2[6832]: sent 13 bytes


            Note the "server" header from the CONNECTED frame, by the way.  The actual 2.2.5 version of HornetQ doesn't provide that header.


            Here's what I get from an Apache Apollo instance, using the same Perl code:


            # 2012/12/21-09:19:44 titan-stomp2[6076]: connect to tcp://localhost:61613 ok:

            # 2012/12/21-09:19:44 titan-stomp2[6076]: Net::STOMP::Client=HASH(0x803c7ee8)->connect()

            # 2012/12/21-09:19:44 titan-stomp2[6076]: encoding CONNECT frame

            # 2012/12/21-09:19:44 titan-stomp2[6076]:  H passcode:password

            # 2012/12/21-09:19:44 titan-stomp2[6076]:  H accept-version:1.0,1.1,1.2

            # 2012/12/21-09:19:44 titan-stomp2[6076]:  H host:localhost

            # 2012/12/21-09:19:44 titan-stomp2[6076]:  H login:admin

            # 2012/12/21-09:19:44 titan-stomp2[6076]: sent 82 bytes

            # 2012/12/21-09:19:44 titan-stomp2[6076]: received 129 bytes

            # 2012/12/21-09:19:44 titan-stomp2[6076]: decoding CONNECTED frame

            # 2012/12/21-09:19:44 titan-stomp2[6076]:  H version:1.2

            # 2012/12/21-09:19:44 titan-stomp2[6076]:  H server:apache-apollo/1.5

            # 2012/12/21-09:19:44 titan-stomp2[6076]:  H host-id:stomp-test2

            # 2012/12/21-09:19:44 titan-stomp2[6076]:  H session:stomp-test2-3ea

            # 2012/12/21-09:19:44 titan-stomp2[6076]:  H heart-beat:100,10000

            # 2012/12/21-09:19:44 titan-stomp2[6076]:  H user-id:admin

            # 2012/12/21-09:19:44 titan-stomp2[6076]: Net::STOMP::Client=HASH(0x803c7ee8)->send()

            # 2012/12/21-09:19:44 titan-stomp2[6076]: encoding SEND frame

            # 2012/12/21-09:19:44 titan-stomp2[6076]:  H destination:jms.queue.NonExistent

            # 2012/12/21-09:19:44 titan-stomp2[6076]:  H receipt:803c7ee8-50d48c20-17bc-fa65-1

            # 2012/12/21-09:19:44 titan-stomp2[6076]:  H content-length:12

            # 2012/12/21-09:19:44 titan-stomp2[6076]:  B 0000 6d657373 61676520 626f6479           mess age  body

            # 2012/12/21-09:19:44 titan-stomp2[6076]: sent 109 bytes

            # 2012/12/21-09:19:44 titan-stomp2[6076]: received 170 bytes

            # 2012/12/21-09:19:44 titan-stomp2[6076]: decoding ERROR frame

            # 2012/12/21-09:19:44 titan-stomp2[6076]:  H message:Internal Server Error\c org.apache.activemq.apollo.stomp.StompProtocolHandler$ProtocolException\c Invalid stomp destination name\c jms.queue.NonExistent

            unexpected ERROR frame received: Internal Server Error: org.apache.activemq.apollo.stomp.StompProtocolHandler$ProtocolException: Invalid stomp destination name: jms.queue.NonExistent

            # 2012/12/21-09:19:44 titan-stomp2[6076]: Net::STOMP::Client=HASH(0x803c7ee8)->disconnect()

            # 2012/12/21-09:19:44 titan-stomp2[6076]: encoding DISCONNECT frame

            # 2012/12/21-09:19:44 titan-stomp2[6076]: sent 13 bytes




            • 3. Re: reliable message sends using STOMP
              Yong Hao Gao Master

              Hi Sam,


              I think this is the current behavior of hornetq. However I think we can give user an option to change that behavior (maybe in the form of an extra header in CONNECT frame).



              • 4. Re: reliable message sends using STOMP
                Yong Hao Gao Master
                1 of 1 people found this helpful
                • 5. Re: reliable message sends using STOMP
                  Sam Bishop Newbie

                  Hi, Howard.


                  Thank you.  I really appreciate your help.


                  I don't know if another header is necessary.  It seems like whether a client cares about whether the send was successful or not is already encoded in whether the client asks for a receipt.


                  However this plays out, I think I've found a workable solution in the meantime.  (In case anyone else has this same question.)  We're already monitoring our dead-letter queue, and I found a send-to-dla-on-no-route flag in the hornetq-configuration.xml file that causes these messages to be sent to the dead-letter queue.


                  Thanks again,


                  • 6. Re: reliable message sends using STOMP
                    Yong Hao Gao Master

                    OK I agree there is no need to add another header. It will just return an error frame whenever the client sends a message to a non-existent destination.