6 Replies Latest reply on Oct 18, 2010 4:04 AM by Eero Kirjavainen

    Stomp message body is empty

    PÃ¥l Evensen Novice

      Hi,

       

      I wrote a working application, using the STOMP interface of HornetQ that worked both with a trunk version of HornetQ and the candidate release. However, after upgrading to 2.1 final, messages received from the STOMP interface no longer has any text in the body. I'm not absolutely sure that the upgrade was what caused it, but it's my best theory for now.

       

      After reading the manual, I'm suspecting it has something to do with a content-length header, but I'm not sure where to set this, as I'm putting messages in the queue in the following way:

       

      clientMessage.getBodyBuffer().writeString(message);
      producer.send(clientMessage);

       

      I've verified that the message variable does contain text, and I've tried the writeByteArray, writeUTF8 and writeSimpleString-methods.

       

      the config looks like this:

       

      <acceptor name="stomp-acceptor">
              <factory-class>org.hornetq.core.remoting.impl.netty.NettyAcceptorFactory</factory-class>
              <param key="protocol"  value="stomp"/>
              <param key="host"  value="localhost"/>
              <param key="port"  value="61613"/>
          </acceptor>

       

      I've done a tcpdump of both the older application, and the new ones. Here's the output:

       

      The "healthy", older one:

       

      MESSAGE
      _HQ_ORIG_ADDRESS:jms.topic.soccer.events.all
      timestamp:1276304427119
      redelivered:false
      _HQ_ORIG_MESSAGE_ID:40802191254
      expires:0
      subscription:subscription/jms.topic.soccer.events.livecenter
      priority:4
      content-length:197
      message-id:40802191255
      type:18
      destination:jms.topic.soccer.events.livecenter

       

      ......{"minute":"87","event-name":"Sjanse","away":"Lillestr..m","home":"Molde","player":"Fall","matchId":"378849","away-goals":"0","home-goals":"3","type":"18","mode":"insert","detailId":"6090290"}.
      ACK
      message-id:40802191255

       

      ...and the new one:

       

      .MESSAGE
      timestamp:1276307227879
      redelivered:false
      expires:0
      subscription:subscription/jms.topic.soccer.events.all
      priority:4
      matchId:505113
      message-id:17179869507
      type:1034
      destination:jms.topic.soccer.events.all

       

      .
      ACK
      message-id:17179869507

       

      #####

       

      I've noticed that the new one does not contain a content-length header.

       

      Here's the queue config:

       

           <queue name="jms.topic.soccer.events.all">
                 <address>jms.topic.soccer.events.all</address>
             <durable>false</durable>
             </queue>

           <queue name="jms.topic.soccer.events.livecenter">
                <address>jms.topic.soccer.events.livecenter</address>
             <durable>false</durable>
             </queue>

       

      <divert name="livecenter-divert">
                  <address>jms.topic.soccer.events.all</address>
                  <forwarding-address>jms.topic.soccer.events.livecenter</forwarding-address>
                  <filter string="type&lt;>'26' AND type&lt;>'27' AND type&lt;>'54'"/>
                  <exclusive>false</exclusive>
              </divert>

       

      Both tests were done by running the following perl script:

       

      #
      # consumer with client side acknowledgment

      #

       

      use Net::STOMP::Client;
      use utf8;

       

      (@ARGV > 1 || die "Too few arguments! Usage: host queue");

       

      my $host = $ARGV[0];
      my $queue = $ARGV[1];


      $stomp = Net::STOMP::Client->new(host => $host, port => 61613);
      $stomp->connect(login => "guest", passcode => "guest");
      printf "Connected\n";
      # declare a callback to be called for each received message frame
      $stomp->message_callback(sub {
      my($self, $frame) = @_;

       

      $self->ack(frame => $frame);
      printf("received: %s\n", $frame->body());
      return($self);

      });

       

      printf "Subscribe\n";

       

      # subscribe to the given queue
      $stomp->subscribe(destination => $queue, ack => "client");
      printf "Waiting\n";
      # wait for a specified message frame
      $stomp->wait_for_frames(callback => sub {
      my($self, $frame) = @_;

       

      if ($frame->command() eq "MESSAGE") {
        # stop waiting for new frames if body is "quit"
        return(1) if $frame->body() eq "quit";
      }
      # continue to wait for more frames
      return(0);
      });
      $stomp->unsubscribe(destination => $queue);
      $stomp->disconnect();

       

      ####

       

      And the session was created calling session = nettyFactory.createSession(); in both cases.

       

      Message was edited by: PÃ¥l Evensen

        • 1. Re: Stomp message body is empty
          Jeff Mesnil Master

          PÃ¥l Evensen wrote:

           

          clientMessage.getBodyBuffer().writeString(message);
          producer.send(clientMessage);

          Could you try again by replacing the code above with:

           

          clientMessage.getBodyBuffer().writeNullableSimpleString(SimpleString.toSimpleString(message));
          producer.send(clientMessage);
          

           

          In order to be able to exchange "strings" between Stomp clients and JMS/HornetQ core clients, we must agree on a format to store the string.

          Using JMS, you need only to use a TextMessage.

          Using HornetQ Core, you need to store the string using writeNullableSimpleString() and not writeString() (which is not intuitive at all and not documented, I agree).

           

          Tell me if this works for you and I'll make sure to document it properly.

          jeff

           

          • 2. Re: Stomp message body is empty
            PÃ¥l Evensen Novice

            Hi Jeff,

             

            This works. Thanks!

             

            Pål

            • 3. Re: Stomp message body is empty
              Eero Kirjavainen Newbie

              Hi,

              im actually strugling with same kind of problem but the message body doesn't show even though I create message as you showed.

              Im using StompConnect and core messaging to send and receive messages on the server side. As a client I have tries normal telnet connection and Python client.

               

              Problem is that when I send a message using coremessaging I can receive the message just fine on the server side.

              But when I to use other clients I can receive message but message body seems to be empty. If I send a message from clientside I can read it just fine from server and from client.

               

              Any ideas what should I try to fix this problem?

              • 4. Re: Stomp message body is empty
                Keith Irwin Newbie

                I can attest that doing this:

                 

                clientMessage.getBodyBuffer().writeNullableSimpleString(SimpleString.toSimpleString(message));

                 

                solved the problem for me.

                • 5. Re: Stomp message body is empty
                  Eero Kirjavainen Newbie

                  For some reason that won't solve my problem. Did you use StompConnect or just HornetQ:s stomp? Since I am currently using StompConnect.

                  Guess I could try withtout StompConnect now that HornetQ can handle stomp too.

                  • 6. Re: Stomp message body is empty
                    Eero Kirjavainen Newbie

                    Hmm, I stopped using StompConnect and used Horneq server to handle stomp connections and there is no problems with messages.

                    I might have misconfigured something at the beginning since message body got messed up when using StompConnect.