-
1. Re: Stomp support for JMS TemporaryQueue planned?
timfox May 2, 2010 12:32 PM (in response to mjustin)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?
mjustin May 3, 2010 2:00 PM (in response to timfox)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 addressrequest
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 brokerrequest
app 2 ("server") sends:
SEND
destination:/remote-temp-queue/ID:mj-PC-50081-1272908928369-3:10:1 <---- reply to temp queuereply
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:0reply
-
3. Re: Stomp support for JMS TemporaryQueue planned?
jmesnil May 4, 2010 7:56 AM (in response to mjustin)1 of 1 people found this helpfulhi 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?
-
4. Re: Stomp support for JMS TemporaryQueue planned?
mjustin May 4, 2010 10:20 AM (in response to jmesnil)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