Stomp support for JMS TemporaryQueue planned?

[mjustin]

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

[timfox]

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

[mjustin]

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

[jmesnil]

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?

[mjustin]

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