Thanks for your response! I don't think that actually fixes this problem,
though. If I leave off the source address and set "dynamic" to true on the
source, I do still end up in ServerSessionImpl.createQueue(), but my user
doesn't seem to have permission to start a temporary queue with the random
UUID name set by ProtonServerSenderContext.initialise(). My user has the
SystemRoles/RPC role and a role that looks like my.queue.name.user prefix.
Since this same user is able to create queues via Core, I'm wondering how
to deal with the AMQP security model mapping here.

Kind regards,

Dirkjan

On Tue, Jan 14, 2020 at 1:25 PM Robbie Gemmell <[email protected]>
wrote:

> The way to create a temp queue is to attach a receiving link with a
> source that sets 'dynamic' to true and with no address, instructing a
> server to create a dynamic/temporary node. The 'reply' attach source
> then contains its address (assuming success and that there is then a
> source).
>
> Robbie
>
> On Mon, 13 Jan 2020 at 10:32, Dirkjan Ochtman <[email protected]> wrote:
> >
> > Hi there,
> >
> > I'm still working on my reimplementation of an AMQP 1.0 client in Rust. I
> > have implemented all the bits that are required to send a message to my
> > target application, but I'm having trouble attaching to the second link
> > that is supposed to be used to receive the responses to the messages. I'm
> > using Artemis 2.6.2 here (I know this is a bit dated -- that's what comes
> > with the vendor application).
> >
> > 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 new 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 have to admit to
> > being confused about the distinction between address and queue in
> > initialise(), so I also tried with
> > "<receive-queue-name>::<receive-queue-name>" as the source address to see
> > if I could trigger a different code path in initialise(). This results
> in a
> > QUEUE_DOES_NOT_EXIST error.
> >
> > This is my attach message:
> >
> > [0, 0, 0, 133, 2, 0, 0, 0, 0, 83, 18, 208, 0, 0, 0, 117, 0, 0, 0, 14,
> 161,
> > 37, 114, 112, 99, 46, 99, 108, 105, 101, 110, 116, 46, 118, 120, 100,
> 105,
> > 114, 46, 49, 50, 53, 52, 50, 57, 54, 53, 55, 53, 55, 48, 52, 57, 48, 48,
> > 56, 51, 52, 48, 82, 1, 65, 64, 64, 0, 83, 40, 208, 0, 0, 0, 53, 0, 0, 0,
> > 11, 161, 37, 114, 112, 99, 46, 99, 108, 105, 101, 110, 116, 46, 118, 120,
> > 100, 105, 114, 46, 49, 50, 53, 52, 50, 57, 54, 53, 55, 53, 55, 48, 52,
> 57,
> > 48, 48, 56, 51, 52, 48, 64, 64, 64, 64, 64, 64, 64, 64, 64, 64, 64, 64,
> 64,
> > 64, 64, 64, 64, 64]
> >
> > Thanks in advance,
> >
> > Dirkjan
>

Reply via email to