> I'm wondering what is the performance penalty of having auto-delete-queues/auto-delete-addresses enabled on a broker with tens of thousands of queues versus using temporary queues?
Predicting performance is tricky given all the variables, but just looking only at the relative "cost" of using a temporary queue vs. a durable queue the durable queue will cost more simply because the disk is involved. However, that may not actually have a statistically significant impact on your overall use-case. Only testing will tell. > If performance impact is considerable, can it be alleviated, by let's say, enabling auto-delete-queues/auto-delete-addresses only on replyTo queues? This was my original suggestion. Notice the match in my example address-setting was "replyTo.#". I think it would make sense to add a new address-setting to make queues temporary. I opened ARTEMIS-5386 [1] to track this. Justin [1] https://issues.apache.org/jira/browse/ARTEMIS-5386 On Mon, Apr 7, 2025 at 6:39 AM Vilius Šumskas <vilius.sums...@rivile.lt.invalid> wrote: > Thank you for your response. > > Suggestion regarding switching to persistent queues looks interesting. I'm > wondering what is the performance penalty of having > auto-delete-queues/auto-delete-addresses enabled on a broker with tens of > thousands of queues versus using temporary queues? Currently we have tens > of thousands of durable queues + max one temporary queue per every durable > queue acting as a replyTo queue (not all temporary queues exist at all > times obviously). If performance impact is considerable, can it be > alleviated, by let's say, enabling auto-delete-queues/auto-delete-addresses > only on replyTo queues? > > -- > Vilius > > -----Original Message----- > From: Justin Bertram <jbert...@apache.org> > Sent: Friday, April 4, 2025 5:18 PM > To: users@activemq.apache.org > Subject: Re: how to separate permissions for replyTo temporary queues > > > <security-setting > > match="^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$"> > > I would not expect this syntax to work. The match for a security-setting > must conform to the wildcard syntax [1] which specifically states: > > ...wildcard characters cannot be used like wildcards in a regular > expression. > > > Are we doing something wrong? Should we just rely on the fact that it > would be very difficult to guess other temp queue names? > > I don't think you're doing anything _wrong_ per se. If you want to use > temporary queues then this is a trade-off you'll have to make. > > However, if you really want to lock everything down then I recommend you > don't use temporary queues and just let the broker deal with automatically > creating and deleting the queues. You can name the queues with a particular > prefix and assign permissions to roles as appropriate, e.g.: > > <address-settings> > ... > <address-setting match="replyTo.#"> > <auto-create-queues>true</auto-create-queues> > <auto-delete-queues>true</auto-delete-queues> > <auto-create-addresses>true</auto-create-addresses> > <auto-delete-addresses>true</auto-delete-addresses> > <address-setting> > ... > </address-settings> > ... > <security-settings> > ... > <security-setting match="replyTo.app1.#"> > <permission type="send" roles="app1" /> > <permission type="consume" roles="app1" /> > </security-setting> > <security-setting match="replyTo.app2.#"> > <permission type="send" roles="app2" /> > <permission type="consume" roles="app2" /> > </security-setting> > ... > </security-settings> > > Then each of your applications could use something like this: > > ... > Session replyTo = session.createQueue("replyTo.app1." + > java.util.UUID.randomUUID().toString()) > ... > message.setJMSReplyTo(replyTo); > ... > > This is all off the top of my head so there might be some errors in there, > but hopefully you get the idea. Let me know if you have further questions! > > > Justin > > [1] > > https://activemq.apache.org/components/artemis/documentation/latest/wildcard-syntax.html#wildcard-syntax > > On Fri, Apr 4, 2025 at 8:14 AM Vilius Šumskas > <vilius.sums...@rivile.lt.invalid> > wrote: > > > Hello, > > > > I’m wondering how one separates permissions of two different roles for > > temporary replyTo queues? Let’s say we have two external users which > > can consume from their durable queues, but they respond to replyTo > > queue created by producer (RPC flow model). We can only set one > > namespace for the queue and limit these users by: > > > > <temporary-queue-namespace>temp</temporary-queue-namespace> > > <security-setting match="temp.#"> > > <permission type="send" roles="roleofbothusers" /> </security-setting> > > > > Or we could do: > > > > <security-setting > > match="^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0 > > -9a-fA-F]{12}$"> <permission type="send" roles=" roleofbothusers " /> > > </security-setting> > > > > But this doesn’t forbit user1 to send messages to temporary queues of > > user2. ReplyTo queues obviously have just random IDs and there is no > > way to differentiate between user1 temporary queues and user2 temporary > queues. > > > > Are we doing something wrong? Should we just rely on the fact that it > > would be very difficult to guess other temp queue names? > > > > -- > > Best Regards, > > > > Vilius Šumskas > > Rivile > > IT manager > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@activemq.apache.org > For additional commands, e-mail: users-h...@activemq.apache.org > For further information, visit: https://activemq.apache.org/contact > >
