RE: Possible regression in MQTT anycast routing over cluster in Artemis 2.44/2.54 (works in 2.27)

[SZEWCZYK Wojciech via users <us...@artemis.apache.org>]

RESTRICTED

Thank you for your reply.

While preparing the test-case, it turned out that the problem disappeared once the automatic creation of queues was disabled.
After changing it to false, everything started working correctly.

<auto-create-addresses>false</auto-create-addresses>
<auto-create-jms-queues>false</auto-create-jms-queues>

Regards,
Wojciech

-----Original Message-----
From: Justin Bertram <jb...@apache.org>
Sent: Tuesday, June 2, 2026 6:29 PM
To: users@artemis.apache.org
Subject: Re: Possible regression in MQTT anycast routing over cluster in Artemis 2.44/2.54 (works in 2.27)

[Nie otrzymujesz często wiadomości e-mail z jbertram@apache.org. Dowiedz się, dlaczego jest to ważne, na stronie https://aka.ms/LearnAboutSenderIdentification ]

SECURITY WARNING: This email originated outside of Alstom. DO NOT open any links /attachments unless you've verified the sender.


I'm not aware of any regressions (intentional or not) in the routing of MQTT messages across a cluster. However, there are over 2,000 commits between 2.27.0 and 2.44.0 so something certainly could have changed without me noticing. Given that MQTT is a fundamentally pub/sub (i.e. multicast) protocol I doubt there are many tests exercising anycast use-cases.

Can you work up a test-case that demonstrates the issue and push it to a GitHub repo?


Justin

On Tue, Jun 2, 2026 at 2:57 AM SZEWCZYK Wojciech via users <us...@artemis.apache.org> wrote:
>
> RESTRICTED
>
>
> Hello everyone,
>
>
>
> we observe what looks like a regression (or behavior change) in MQTT message routing in a 2-node Artemis cluster.
>
>
>
> Environment
>
>   Artemis versions tested:
>
> works: 2.27
>
> problematic: 2.44, 2.53, 2.54
>
> Topology: 2 broker nodes in cluster
>
> Protocols used by producers/consumers: MQTT, CORE, STOMP
>
> ANYCAST queue
>
>
>
> Configuration (relevant parts)
>
>   Address/queue configured as ANYCAST:
>
> address: test1
>
> queue: test1
>
>   Cluster connection:
>
> message-load-balancing=ON_DEMAND
>
> MQTT clients publish to: jms/queue/test1
>
>
>
> Observed behavior
>
> In single-broker setup: all MQTT messages are routed correctly.
>
> In 2-node cluster:
>
> only every second MQTT message is routed to queue correctly,
>
> the others appear as unrouted on the opposite node (UnRoutedMessageCount increases).
>
> CORE and STOMP traffic routes correctly in the same cluster.
>
>
>
> Behavior is symmetric:
>
> publishing to node1: failures appear on node2,
>
> publishing to node2: failures appear on node1.
>
>
>
>
>
> Is this a known behavior change/regression in MQTT routing across clustered brokers between 2.27 and 2.44+?
>
> Is there any required additional configuration for MQTT anycast routing in cluster mode in newer versions?
>
>
>
> Thanks in advance for your help.
>
> Best regards,
>
> Wojciech
>
>
>
>
> ________________________________
> CONFIDENTIALITY : This e-mail and any attachments are confidential and may be privileged. If you are not a named recipient, please notify the sender immediately and do not disclose the contents to another person, use it for any purpose or store or copy the information in any medium.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@artemis.apache.org
For additional commands, e-mail: users-help@artemis.apache.org


________________________________
CONFIDENTIALITY : This e-mail and any attachments are confidential and may be privileged. If you are not a named recipient, please notify the sender immediately and do not disclose the contents to another person, use it for any purpose or store or copy the information in any medium.

Re: Possible regression in MQTT anycast routing over cluster in Artemis 2.44/2.54 (works in 2.27)

[Justin Bertram <jb...@apache.org>]

Does that mean you have a test-case that reproduces the problem when
auto-create is enabled? If so, could you share it?


Justin

On Thu, Jul 2, 2026 at 8:12 AM SZEWCZYK Wojciech via users
<us...@artemis.apache.org> wrote:
>
> RESTRICTED
>
> Thank you for your reply.
>
> While preparing the test-case, it turned out that the problem disappeared once the automatic creation of queues was disabled.
> After changing it to false, everything started working correctly.
>
> <auto-create-addresses>false</auto-create-addresses>
> <auto-create-jms-queues>false</auto-create-jms-queues>
>
> Regards,
> Wojciech
>
> -----Original Message-----
> From: Justin Bertram <jb...@apache.org>
> Sent: Tuesday, June 2, 2026 6:29 PM
> To: users@artemis.apache.org
> Subject: Re: Possible regression in MQTT anycast routing over cluster in Artemis 2.44/2.54 (works in 2.27)
>
> [Nie otrzymujesz często wiadomości e-mail z jbertram@apache.org. Dowiedz się, dlaczego jest to ważne, na stronie https://aka.ms/LearnAboutSenderIdentification ]
>
> SECURITY WARNING: This email originated outside of Alstom. DO NOT open any links /attachments unless you've verified the sender.
>
>
> I'm not aware of any regressions (intentional or not) in the routing of MQTT messages across a cluster. However, there are over 2,000 commits between 2.27.0 and 2.44.0 so something certainly could have changed without me noticing. Given that MQTT is a fundamentally pub/sub (i.e. multicast) protocol I doubt there are many tests exercising anycast use-cases.
>
> Can you work up a test-case that demonstrates the issue and push it to a GitHub repo?
>
>
> Justin
>
> On Tue, Jun 2, 2026 at 2:57 AM SZEWCZYK Wojciech via users <us...@artemis.apache.org> wrote:
> >
> > RESTRICTED
> >
> >
> > Hello everyone,
> >
> >
> >
> > we observe what looks like a regression (or behavior change) in MQTT message routing in a 2-node Artemis cluster.
> >
> >
> >
> > Environment
> >
> >   Artemis versions tested:
> >
> > works: 2.27
> >
> > problematic: 2.44, 2.53, 2.54
> >
> > Topology: 2 broker nodes in cluster
> >
> > Protocols used by producers/consumers: MQTT, CORE, STOMP
> >
> > ANYCAST queue
> >
> >
> >
> > Configuration (relevant parts)
> >
> >   Address/queue configured as ANYCAST:
> >
> > address: test1
> >
> > queue: test1
> >
> >   Cluster connection:
> >
> > message-load-balancing=ON_DEMAND
> >
> > MQTT clients publish to: jms/queue/test1
> >
> >
> >
> > Observed behavior
> >
> > In single-broker setup: all MQTT messages are routed correctly.
> >
> > In 2-node cluster:
> >
> > only every second MQTT message is routed to queue correctly,
> >
> > the others appear as unrouted on the opposite node (UnRoutedMessageCount increases).
> >
> > CORE and STOMP traffic routes correctly in the same cluster.
> >
> >
> >
> > Behavior is symmetric:
> >
> > publishing to node1: failures appear on node2,
> >
> > publishing to node2: failures appear on node1.
> >
> >
> >
> >
> >
> > Is this a known behavior change/regression in MQTT routing across clustered brokers between 2.27 and 2.44+?
> >
> > Is there any required additional configuration for MQTT anycast routing in cluster mode in newer versions?
> >
> >
> >
> > Thanks in advance for your help.
> >
> > Best regards,
> >
> > Wojciech
> >
> >
> >
> >
> > ________________________________
> > CONFIDENTIALITY : This e-mail and any attachments are confidential and may be privileged. If you are not a named recipient, please notify the sender immediately and do not disclose the contents to another person, use it for any purpose or store or copy the information in any medium.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@artemis.apache.org
> For additional commands, e-mail: users-help@artemis.apache.org
>
>
> ________________________________
> CONFIDENTIALITY : This e-mail and any attachments are confidential and may be privileged. If you are not a named recipient, please notify the sender immediately and do not disclose the contents to another person, use it for any purpose or store or copy the information in any medium.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@artemis.apache.org
> For additional commands, e-mail: users-help@artemis.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@artemis.apache.org
For additional commands, e-mail: users-help@artemis.apache.org