Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Not A Problem
-
2.6.2
-
None
-
None
Description
When attaching as a receiver to create a new queue, it appears Artemis will try to create a durable queue by default, even if I specify that the queue should not be durable. If my user does not have permission to create durable queues (even though it has permission to create non-durable queues), creation of the queue will fail with a permission error.
More context:
The application I'm targeting usually uses Core messages to do RPC, but it accepts AMQP messages as well, so it could be that there is a mismatch here between how things are set up.
When using Core, I see that ServerSessionPacketHandler triggers on a packet with type -12 to create the queue with a well-defined name, which in the end dispatches to ServerSessionImpl.createQueue() with temporary = true and durable = false. This is the behavior I'm seeking to replicate. However, all my attempts to create to a temporary non-durable queue by attaching to it with AMQP seem to be failing so far.
With my AMQP client, I try to create the response queue by attaching to it with source address = <receive-queue-name>. This lets me end up in ProtonServerSenderContext.initialise() by way of AMQPSessionContext.addSender(). However, this throws a permission error (AMQ119213, my user does not have permission for CREATE_DURABLE_QUEUE). This is surprising to me because I leave the "durable" field as default, which should mean to default to no durability. It seems to happen because AMQPSessionCallback.queueQuery() calls (through some indirection) ServerSessionImpl.createQueue() with durable = true.
I could potentially create non-durable queues by setting dynamic = true, but in that case Artemis will create the queue with random UUID name, whereas my user only has permission to create queues with a name with a specific prefix.