[
https://issues.apache.org/jira/browse/ARTEMIS-1905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram resolved ARTEMIS-1905.
-------------------------------------
Resolution: Not A Problem
bq. ...that is non-standard since there is no {{destination-type}} header
defined in STOMP protocol.
It doesn't make a lot of sense to talk about "standard" ways to define the
semantics of a destination in STOMP because there intentionally aren't any
standards regarding destination semantics (at least from what I can tell).
[When providing an overview of the protocol the STOMP 1.2 specification
says|https://stomp.github.io/stomp-specification-1.2.html#Protocol_Overview]:
bq. A STOMP server is modelled as a set of destinations to which messages can
be sent. The STOMP protocol treats destinations as opaque string and their
syntax is server implementation specific. Additionally STOMP does not define
what the delivery semantics of destinations should be. The delivery, or
"message exchange", semantics of destinations can vary from server to server
and even from destination to destination. This allows servers to be creative
with the semantics that they can support with STOMP.
Then [when discussing the destination header in the {{SEND}} frame it
says|https://stomp.github.io/stomp-specification-1.2.html#SEND]:
bq. Note that STOMP treats this destination as an opaque string and no delivery
semantics are assumed by the name of a destination. You should consult your
STOMP server's documentation to find out how to construct a destination name
which gives you the delivery semantics that your application needs.
Finally, [when discussing the {{SUBSCRIBE}} frame it
says|https://stomp.github.io/stomp-specification-1.2.html#SUBSCRIBE]:
bq. STOMP servers MAY support additional server specific headers to customize
the delivery semantics of the subscription. Consult your server's documentation
for details.
Therefore, the broker supports a handful of different ways to specify which
semantics are desired both on the client-side and broker-side.
On the client-side the user can specify the {{destination-type}} or
{{subscription-type}} headers for the {{SEND}} and {{SUBSCRIBE}} frames
respectively. These headers are discussed further in the "Mapping Stomp
destinations to addresses and queues" section of the [Protocols and
Interoperability|https://activemq.apache.org/artemis/docs/latest/protocols-interoperability.html]
chapter.
On the broker-side there are two main options:
# Using prefixes.
# Using address settings.
Using prefixes involves specifying the {{anycastPrefix}} and/or the
{{multicastPrefix}} on the acceptor which the STOMP client is using. For the
STOMP use-case these prefixes tell the broker that destinations using them
should be treated as anycast or multicast. For example, if the acceptor has
{{anycastPrefix=queue/}} then when a STOMP client sends a message to
{{destination:queue/foo}} the broker will auto-create the address {{foo}} and
queue {{foo}} appropriately as anycast. Additionally, if the acceptor has
{{multicastPrefix=topic/}} then when a STOMP client sends a message to
{{destination:topic/bar}} the broker will auto-create the address {{bar}} as
multicast, but it won't create a queue since multicast (i.e. pub/sub) semantics
require a client to explicitly create a subscription to receive those messages.
Using address settings involves defining address-setting elements whose match
corresponds with the destination names the clients will use along with the
proper delimiter to enabled matching. For example, broker.xml could use the
following:
{code:xml}
<address-settings>
<address-setting match="queue/#">
<default-address-routing-type>ANYCAST</default-address-routing-type>
<default-queue-routing-type>ANYCAST</default-queue-routing-type>
</address>
<address-setting match="topic/#">
<default-address-routing-type>MULTICAST</default-address-routing-type>
<default-queue-routing-type>MULTICAST</default-queue-routing-type>
</address>
</address-settings>
<wildcard-addresses>
<delimiter>/</delimiter>
</wildcard-addresses>
{code}
Then if a STOMP client sends a message to {{destination:queue/foo}} the broker
will auto-create the address {{queue/foo}} and queue {{queue/foo}}
appropriately as anycast. Additionally, if a STOMP client sends a message to
{{destination:topic/bar}} the broker will auto-create the address {{topic/bar}}
as multicast, but it won't create a queue as previously explained.
Note: Using prefixes and address settings ultimately results in different
address and queue names because using the prefixes will strip the prefix
whereas using the address settings won't.
> When using JMS API over STOMP protocol only multicast destinations are created
> ------------------------------------------------------------------------------
>
> Key: ARTEMIS-1905
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1905
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker, STOMP
> Affects Versions: 2.6.0
> Reporter: Tom Ross
> Assignee: Justin Bertram
> Priority: Major
>
> When calling JMS API {{createQueue()}} only multicast destinations are
> created in the broker back end. The call to {{createQueue()}} should result
> in a anycast destination to be created.
> Also when sending a frame like would result in multicast destination.
> {noformat}
> SEND
> destination:queue/foo
> text
> {noformat}
> It's possible to add {{destination-type}} header to the frame
> {noformat}
> SEND
> destination:queue/foo
> destination-type:ANYCAST
> text
> {noformat}
> However, that is non-standard since there is no {{destination-type}} header
> defined in STOMP protocol.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
