I went ahead and filed https://issues.apache.org/jira/browse/ARTEMIS-2605 for this. I hope there is some way to resolve this problem, as it means I currently can't use my AMQP client with Artemis due to what looks like an Artemis implementation issue.
Kind regards, Dirkjan On Thu, Jan 16, 2020 at 3:54 PM Dirkjan Ochtman <dirk...@ochtman.nl> wrote: > 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 <robbie.gemm...@gmail.com> > 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 <dirk...@ochtman.nl> 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 >> >
