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

    Stomp support for JMS TemporaryQueue planned?

    Michael Justin Novice



      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?




        • 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



          • 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:
            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




            app 2 ("server") receives:
            destination:/queue/client.messages                   <------- incoming message on normal queue
            reply-to:/remote-temp-queue/ID:mj-PC-50081-1272908928369-3:10:1   <----- temp queue reply-to assigned by broker




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




            app 1 ("client") receives:
            destination:/remote-temp-queue/ID:mj-PC-50081-1272908928369-3:10:1  <---- received from temp queue



            • 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.



              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:




                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