Please use the users list for such questions going forward. The mailing lists strip almost every attachment/insertion, so your images have not made it.
Artemis treats 'mutlicast' addresses+queues as being like topic subscriptions, and in these cases when it creates the subscription-backing-queue it adds the filter between the address and the queue to stop any non-matching messages accumulating. In JMS for example, changing the filter on such an existing named topic subscription is explicitly required to be treated the same as destroying the prior subscription and creating a new one with the new filter, which in this case occurs server-side and is presumably what you are seeing in action, and perhaps referenced in the image I cant see. The AMQP 1.0 protocol does not cover the behaviour of changing a selector filter on such a 'topic subscription backing-queue' because it doesnt really cover 'topic' subscription handling either to begin with, instead more P2P message delivery between 'nodes' with largely out-of-band behaviour. The selector filter itself isnt defined by the protocol spec either. I'm dont know if the filter can be administratively changed on an existing sub-backing like queue or not...perhaps more likely for queues that are explicitly config-defined, but again not sure for that case either. If you want a given existing queue to facilitate different filters either at the same time or over time, and still retain prior messages that may not match, and update the filter from the client alone, you might need to use an 'anycast' queue where the filtering always only happens on the consumer itself (and not between the address and the queue), and different consumers can then have different filters either at the same time or over time. If you are using auto-creation then the broker defaults to 'multicast' if not told otherwise somehow, but you can govern the behaviour either via the address settings config in broker.xml etc, or you can request particular treatment via clients, e.g in this case by adding a "queue" (anycast) or "topic" (multicast) source capability when establishing the consumer link (or similarly as target capability for a producer link). E.g see https://github.com/amqphub/equipage/blob/main/amqpnetlite/AutoCreate/QueueReceive/QueueReceive.cs#L55-L58 for that You might additionally or alternatively find some use for the FQQN syntax where you can specify both the address and queue names together in a formatted way, and which can be used to override certain routing behaviour treatment in some cases (though I think in that case it could also just refuse a new/updated consumers attempts on a FQQN multicast queue due to a filter mismatch..I forget now, theres a lot of different behaviours involved here and they have changed over time): https://activemq.apache.org/components/artemis/documentation/latest/address-model.html#fully-qualified-queue-names On Wed, 10 Jan 2024 at 13:24, rusu ionut <ionut_rusu_2...@yahoo.ro.invalid> wrote: > Hello everyone, > > I am using ActiveMQ Artemis 2.31.2 and Amqpnetlite library in .NET. > I want to simulate a publish-subscribe scenario where I have an address as > a topic, and then multiple queues connected to that address. Each queue > will have a filter that checks the message's subject (JMSType). This way I > can have the same behaviour as RabbitMQ (topic edge/publish-subscribe). > Everything works as expected when I create addresses and queues using the > Amqpnetlite library, the only thing that I need and it doesn't work, is to > change the filter for a queue after it was created. I tried to send a > Source with an addres of an existing queue and the value of the filter > modified, but this resulted in the queue to be deleted and recreated with > the new filter. This means that all the messages will be lost and will only > work if the queue has no consumer. > > The Artemis implementation: > > [image: Imagine în linie] > > The AMQP protocol states that the properties of a terminus should be > updated if they don't match the one sent by the client: > > [image: Imagine în linie] > Is this a bug or it was intended to have this behavior and not follow the > AMQP protocol? Can it be changed in a way that the filter is updated > without deleting the queue? > > Best regards > >
