Details
-
New Feature
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
1.0-beta5
-
None
Description
Temporary destinations are typically used to receive response messages in
a request/response messaging exchange. A temporary destination can only
be consumed by a subscription created on the connection which is associated
with the temporary destination. Once the connection is closed, all associated
temporary destinations are removed. Temporary destinations are prefixed with:
- `/temp-queue/` - For temporary queues. Has the same delivery semantics as queues.
- `/temp-topic/` - For temporary topics. It has the same delivery semantics of topics.
In a request/response scenario, you would first subscribe to the temporary topic:
SUBSCRIBE
id:mysub
destination:/temp-queue/example
^@
Then you would send a request with the reply-to header set to the temporary destination.
Example:
SEND
destination:/queue/PO.REQUEST
reply-to:/temp-queue/example
PO145
^@
The consumer receiving the request will receive a message similar to:
MESSAGE
subscription:foo
reply-to:/queue/temp.default.23.example
destination:/queue/PO.REQUEST
reply-to:/temp-queue/example
PO145
Notice that the reply-to` header value is updated from a temporary destination
name to normal destination name. The subscription servicing he requests should respond
to the updated destination value (`/queue/temp.default.23.example` in the example above).
Temporary destination names actually map to normal queues and topics. They just have
a `temp.<broker_id>.<connection_id>.` prefix. Any destination which starts with
`temp.` has a security policy which only allows the connection which created it
to subscribe from it. These destinations are also auto deleted once the connection
is closed.
Provides a better fix for APLO-86 and removes support for the 'temp:true' header on the subscribe frame.