You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by CASAUX Nicolas <ni...@soprasteria.com> on 2023/04/04 14:24:49 UTC
Broker redelivery - NACK and authorization issue
Hello ActiveMQ users,
I have a question regarding ActiveMQ 5.16.x and redelivery of messages.
I set up the broker with the configuration described in paragraph “Broker Redelivery” of page https://activemq.apache.org/message-redelivery-and-dlq-handling .
The client “abc” of the broker has a read only access to a queue which is dedicated to him (It’s a queue based on a topic, hence named like “Consumer.abc.VirtualTopic.xxx”).
The issue is that, when the client sends a “NACK” command over Stomp over Websocket, the broker fails saying user “abc” has is not authorized to write to the queue “Consumer.abc.VirtualTopic.xxx”, which is correct.
My question is: is that the expected behaviour ? To be able to use a NACK command, you need to be allowed to write to the queue ?
Thanks in advance for your guidance 😊
Nicolas
C2 – Usage restreint
RE: Broker redelivery - NACK and authorization issue
Posted by CASAUX Nicolas <ni...@soprasteria.com>.
FYI, I reproduced the case with ActiveMQ 5.17.4, I will open a JIRA tomorrow.
Nicolas
C2 – Usage restreint
-----Message d'origine-----
De : CASAUX Nicolas
Envoyé : mardi 4 avril 2023 17:59
À : users@activemq.apache.org
Objet : RE: Broker redelivery - NACK and authorization issue
Thank you Matt,
I'll try to reproduce it in a simple way, with a 5.17.x version of ActiveMQ, and open a JIRA.
Nicolas
C2 – Usage restreint
-----Message d'origine-----
De : Matt Pavlovich <ma...@gmail.com> Envoyé : mardi 4 avril 2023 17:06 À : users@activemq.apache.org Objet : Re: Broker redelivery - NACK and authorization issue
Hi Nicolas-
No, a ’NACK’ should not count as a ‘write’ to the queue. However, we need additional detail (and preferably a reproducible unit test) to confirm it is a bug, or configuration issue.
Please create a JIRA (https://issues.apache.org/jira), and include your unit test and activemq.xml configuration.
Thanks,
Matt Pavlovich
> On Apr 4, 2023, at 9:24 AM, CASAUX Nicolas <ni...@soprasteria.com> wrote:
>
> Hello ActiveMQ users,
>
> I have a question regarding ActiveMQ 5.16.x and redelivery of messages.
> I set up the broker with the configuration described in paragraph “Broker Redelivery” of page https://activemq.apache.org/message-redelivery-and-dlq-handling .
>
> The client “abc” of the broker has a read only access to a queue which is dedicated to him (It’s a queue based on a topic, hence named like “Consumer.abc.VirtualTopic.xxx”).
> The issue is that, when the client sends a “NACK” command over Stomp over Websocket, the broker fails saying user “abc” has is not authorized to write to the queue “Consumer.abc.VirtualTopic.xxx”, which is correct.
>
> My question is: is that the expected behaviour ? To be able to use a NACK command, you need to be allowed to write to the queue ?
>
> Thanks in advance for your guidance 😊
>
> Nicolas
>
>
>
> C2 – Usage restreint
RE: Broker redelivery - NACK and authorization issue
Posted by CASAUX Nicolas <ni...@soprasteria.com>.
Thank you Matt,
I'll try to reproduce it in a simple way, with a 5.17.x version of ActiveMQ, and open a JIRA.
Nicolas
C2 – Usage restreint
-----Message d'origine-----
De : Matt Pavlovich <ma...@gmail.com>
Envoyé : mardi 4 avril 2023 17:06
À : users@activemq.apache.org
Objet : Re: Broker redelivery - NACK and authorization issue
Hi Nicolas-
No, a ’NACK’ should not count as a ‘write’ to the queue. However, we need additional detail (and preferably a reproducible unit test) to confirm it is a bug, or configuration issue.
Please create a JIRA (https://issues.apache.org/jira), and include your unit test and activemq.xml configuration.
Thanks,
Matt Pavlovich
> On Apr 4, 2023, at 9:24 AM, CASAUX Nicolas <ni...@soprasteria.com> wrote:
>
> Hello ActiveMQ users,
>
> I have a question regarding ActiveMQ 5.16.x and redelivery of messages.
> I set up the broker with the configuration described in paragraph “Broker Redelivery” of page https://activemq.apache.org/message-redelivery-and-dlq-handling .
>
> The client “abc” of the broker has a read only access to a queue which is dedicated to him (It’s a queue based on a topic, hence named like “Consumer.abc.VirtualTopic.xxx”).
> The issue is that, when the client sends a “NACK” command over Stomp over Websocket, the broker fails saying user “abc” has is not authorized to write to the queue “Consumer.abc.VirtualTopic.xxx”, which is correct.
>
> My question is: is that the expected behaviour ? To be able to use a NACK command, you need to be allowed to write to the queue ?
>
> Thanks in advance for your guidance 😊
>
> Nicolas
>
>
>
> C2 – Usage restreint
Re: Broker redelivery - NACK and authorization issue
Posted by Matt Pavlovich <ma...@gmail.com>.
Hi Nicolas-
No, a ’NACK’ should not count as a ‘write’ to the queue. However, we need additional detail (and preferably a reproducible unit test) to confirm it is a bug, or configuration issue.
Please create a JIRA (https://issues.apache.org/jira), and include your unit test and activemq.xml configuration.
Thanks,
Matt Pavlovich
> On Apr 4, 2023, at 9:24 AM, CASAUX Nicolas <ni...@soprasteria.com> wrote:
>
> Hello ActiveMQ users,
>
> I have a question regarding ActiveMQ 5.16.x and redelivery of messages.
> I set up the broker with the configuration described in paragraph “Broker Redelivery” of page https://activemq.apache.org/message-redelivery-and-dlq-handling .
>
> The client “abc” of the broker has a read only access to a queue which is dedicated to him (It’s a queue based on a topic, hence named like “Consumer.abc.VirtualTopic.xxx”).
> The issue is that, when the client sends a “NACK” command over Stomp over Websocket, the broker fails saying user “abc” has is not authorized to write to the queue “Consumer.abc.VirtualTopic.xxx”, which is correct.
>
> My question is: is that the expected behaviour ? To be able to use a NACK command, you need to be allowed to write to the queue ?
>
> Thanks in advance for your guidance 😊
>
> Nicolas
>
>
>
> C2 – Usage restreint