Github user mtaylor commented on the issue:
https://github.com/apache/activemq-artemis/pull/1775
@jostbg The point is, if you want the broker to create something for you,
then the broker needs to know what to create. I used JMS clients as an example
as they are usually specific about what they want, the same thing can happen in
other protocols. In the JMS case the client sends the broker the information
it needs to create the appropriate queue with some additional bits of info.
The JMS client doesn't say, hey I want a durable queue with these properties
(except the CORE client as it's tied to the Artemis implementation). Instead,
say the QPID AMQP client says, hey I want a JMS Durable Subscription. It does
this by setting some special JMS AMQP properties. The AMQP protocol handler
reads these properties and decides how to interpret them. In some cases these
get translated to durable queues, in others they are translated to non-durable
queues. Artemis has a underlying model that is protocol agnostic, so things
are translated from API/protocol specifics down to the und
erlying model.
Coming back to your comments on
https://issues.apache.org/jira/browse/ARTEMIS-1582.
There are two meanings of durable. Durable in the context of a
subscription (which is tied to the consumer connection life cycle), and durable
in the context persistence (tied to the broker life cycle). The reason you are
seeing some queues be durable and others not, is because this is how the JMS
spec is implemented using the underlying Artemis model. An non-durable
subscription means that the client only gets messages while it's connected. If
the server crashes, the client isn't connected anymore.
In this case, the spec says, its fine to lose all the messages. For this
reason there's no point creating a durable queue. In the JMS Queue (ANYCAST)
scenario we need a durable queue because the messages outlive the subscriber
connection life cycle. This is also true for durable subscriptions.
Regarding your comment on misconfiguration, yes you can do that, but you're
specifically overriding broker behaviour to do something else. You're welcome
to do this, but you have to be aware that you are breaking protocol/API
contracts by doing so.
---
