Understood. So one probable performance penalty would be due to queues sitting
on disk. Another penalty I suppose is queue scanning every
"address-queue-scan-period"? If we have thousands of queues and the scan needs
to check every queue for messages and consumer count I suppose this is also
relatively slow operation?
--
Vilius
-----Original Message-----
From: Justin Bertram <[email protected]>
Sent: Monday, April 7, 2025 8:04 PM
To: [email protected]
Subject: Re: how to separate permissions for replyTo temporary queues
> 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
<[email protected]> 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 <[email protected]>
> Sent: Friday, April 4, 2025 5:18 PM
> To: [email protected]
> 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/wi
> ldcard-syntax.html#wildcard-syntax
>
> On Fri, Apr 4, 2025 at 8:14 AM Vilius Šumskas
> <[email protected]>
> 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: [email protected]
> For additional commands, e-mail: [email protected] For
> further information, visit: https://activemq.apache.org/contact
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
For further information, visit: https://activemq.apache.org/contact
