4 Replies Latest reply on May 4, 2010 10:20 AM by Michael Justin

    Stomp support for JMS TemporaryQueue planned?

    Michael Justin Novice

      Hello,

       

      it would be great if HornetQ 2.1 could also expose JMS temporary destinations (for example the TemporaryQueue via Session#createTemporaryQueue) for RPC style communication. Is this planned for a later release?

       

      Regards,

      Michael

        • 1. Re: Stomp support for JMS TemporaryQueue planned?
          Tim Fox Master

          All queues on the HornetQ server should already be accessible via STOMP.

           

          Can you show some test code that demonstrates the problem?

           

          I'm guessing you didn't prefix the JMS queue name with jms.queue.

           

          A JMS queue is just a core queue with the prefix jms.queue

           

          http://hornetq.sourceforge.net/docs/hornetq-2.0.0.GA/user-manual/en/html/jms-core-mapping.html

          • 2. Re: Stomp support for JMS TemporaryQueue planned?
            Michael Justin Novice

            Hello Tom,

             

            the problem with temporary queues and Stomp is that the queue name is not known to the client who creates it.

             

            In the HornetQ JMS class HornetQSession, the createTemporaryQueue method takes no arguments. The temporary queue can be used as the JMSReplyTo destination for messages sent to the broker (as explained in http://onjava.com/pub/a/onjava/2007/04/10/designing-messaging-applications-with-temporary-queues.html).

             

            With the standard Stomp protocol, there is no way for the client to specify that a queue is a temporary queue, or to get the temporary queue name. For this reason, in OpenMQ and ActiveMQ implementations of Stomp, special queue name prefixes are used to indicate a temporary queue, for example "/temp-queue/" prefix denotes a TemporaryQueue (with name follows the  prefix) in OpenMQ, and "temporary_destination://queue/" must be used to send reply messages to a MESSAGE frame's reply-to  destination. (https://mq.dev.java.net/4.4-content/stomp-funcspec.html).

             

            Here is an example for a request-reply communication between two Stomp clients iin ActiveMQ:

             

            app 1 ("client") sends:
            SEND
            destination:/queue/client.messages  <------ client sends to a normal queue
            reply-to:/temp-queue/0      <------- but uses special /temp-queue/ prefix in the reply-to address

             

            request

             

            app 2 ("server") receives:
            MESSAGE
            message-id:ID:mj-PC-50081-1272908928369-3:10:-1:1:1
            destination:/queue/client.messages                   <------- incoming message on normal queue
            timestamp:1272908931851
            expires:0
            subscription:{76652F18-856D-42A0-8637-6F87CC6320D8}
            priority:0
            reply-to:/remote-temp-queue/ID:mj-PC-50081-1272908928369-3:10:1   <----- temp queue reply-to assigned by broker

             

            request

             

            app 2 ("server") sends:
            SEND
            destination:/remote-temp-queue/ID:mj-PC-50081-1272908928369-3:10:1  <---- reply to temp queue

             

            reply

             

            app 1 ("client") receives:
            MESSAGE
            message-id:ID:mj-PC-50081-1272908928369-3:9:-1:1:1
            destination:/remote-temp-queue/ID:mj-PC-50081-1272908928369-3:10:1  <---- received from temp queue
            timestamp:1272908931859
            expires:0
            subscription:{CB137D70-ACA6-4CB4-AF7E-0D01CBC3C2A0}
            priority:0

             

            reply

            • 3. Re: Stomp support for JMS TemporaryQueue planned?
              Jeff Mesnil Master

              hi michael,

               

              this is indeed a valid use case.

              We could add support for special destination semantic:

              - /temp-queue/XXXX to create a JMS temporary queue on the server side

              - /temp-topic/XXXX to create a JMS temporary topic on the server side

               

              these temporary destination would exist for the duration of the Stomp connection.

               

              wdyt?

              Do not hesitate to open a JIRA issue for it?

              1 of 1 people found this helpful
              • 4. Re: Stomp support for JMS TemporaryQueue planned?
                Michael Justin Novice

                hello Jeff,

                 

                many thanks for your answer, the feature suggestion is now in JIRA, including two examples of existing implementations:

                 

                https://jira.jboss.org/jira/browse/HORNETQ-381

                 

                It looks like both implementations use a different syntax of the destination which has been created by the broker on behalf of the client (temp-queue vs. remote-temp-queue), I guess this is an easy way to see the difference between the temp destination name assigned by the client and the name assigned by the broker