1 Reply Latest reply on May 27, 2010 3:48 AM by jmesnil

    Using Hornetq with Stomp Message Expiration.

    mpeitz May 26, 2010 3:16 PM

      Hello,

      I am currently doing some testing of Hornetq using a stomp client (we are a .NET shop) , after a few early struggles things are finally starting to come together. I am really starting to like working with Hornetq and can't wait to fully integrate it into our systems. Though I ran into what I believe is a bug in the stomp protocol code this afternoon. I was trying to set the expiration for a message through stomp for the example Queue, and just couldn't get it figured out. So I decided to check the code  to see what exactly I need to pass to Hornetq to set the expiration time. After walking through the process, I discovered something that appears to be strange to me. Starting on line 65 of StompUtils.java there is this code snippet

            Object replyTo = headers.remove(Stomp.Headers.Send.REPLY_TO);
      if (replyTo != null)
      {
         msg.putStringProperty(ClientMessageImpl.REPLYTO_HEADER_NAME, SimpleString.toSimpleString((String)replyTo));
      }
      String expiration = (String)headers.remove(Stomp.Headers.Send.REPLY_TO);
      if (expiration != null)
      {
         msg.setExpiration(Long.parseLong(expiration));
      }

       

      Shouldn't this line

       

      String expiration = (String)headers.remove(Stomp.Headers.Send.REPLY_TO);

       

      Be

       

      String expiration = (String)headers.remove(Stomp.Headers.Send.EXPIRATION);

       

      I checked the JIRA and didn't see any known issues with message expiration over STOMP. It seems like a small problem so I didn't see the need to build a java project to test it (I can if you need me to but so far I have been doing a lot of my stomp work with a .NET client and I know you don't want that). Am I correct that this code is wrong, or am I totally off base on how the conversion from stomp to Core is done?

      Thanks in Advance,

      Matt