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
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
1 of 1 people found this helpful
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?
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