You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by "Shields, Paul Michael" <pa...@hpe.com> on 2023/03/20 14:37:29 UTC
MQTT retained messages and a Clustered Broker
Hi,
I have a clustered broker setup using loadbalance feature. I am having trouble getting MQTT retained messages feature to have the same last messages available on each of the brokers in my cluster. I need each client that connects to any of the brokers in the cluster to receive all the retained messages from all brokers, so they have a complete view of my system. I have tried this in the broker config file but it does not replicate all the retained messages to each broker. What other parameters do I need to set to get all retained messages to any connecting client? Any help greatly appreciated.
<address-settings>
<!--default for catch all-->
<address-setting match="#">
<redistribution-delay>0</redistribution-delay>
<dead-letter-address>DLQ</dead-letter-address>
<expiry-address>ExpiryQueue</expiry-address>
<redelivery-delay>0</redelivery-delay>
<auto-create-queues>true</auto-create-queues>
<auto-create-addresses>true</auto-create-addresses>
<auto-delete-queues>false</auto-delete-queues>
<auto-delete-addresses>false</auto-delete-addresses>
</address-setting>
</address-settings>
Best Regards,
Paul Shields
Re: MQTT retained messages and a Clustered Broker
Posted by "Shields, Paul Michael" <pa...@hpe.com>.
Hi Justin,
Thanks for your response. To elaborate on my use-case. I have a client server application that uses multiple servers for horizontal scaling. The servers run in containers within a Kubernetes environment. The client attaches to a server and maintains that connection over time. If the server that the client is attached to goes down, the client performs a failover action to one of the remaining servers. If a client goes down, the server needs to clean up its resources.cccccckvnkdibdjcjhutceveenehvtjinnleuvilvdjt
I am using MQTT for node up/down health system. When a client or server in my application becomes available, it connects to the MQTT broker and Publishes on a topic that the node is up and then registers a Last Will and Testament that is the node down health state. The servers in my application subscribe to client topics and monitor node health so they can cleanup resources when clients go away. The clients in my application subscribe to the server topics and monitor for the node health state. The client will perform failover if it receives the LWT message from the server it was connected to. The client also builds a list of available servers from the server topics being published. Retained messages are very important to my application since the retained messages provide the state of my application when a new client or server is added to my application. All of the support services for my application run in containers. I used the ArtemisCloud Operator as a means of deploying Artemis in Kubernetes. It sets up a cluster by default. My application needs HA. This includes the services it depends on. My Application can support up to 10K nodes, so I may need scaling in the MQTT node health system?
Thanks,
Paul
On 3/27/23, 12:52 PM, "Justin Bertram" <jb...@apache.org> wrote:
This functionality isn't supported, and while it may be technically
feasible to implement I'm not sure how much sense it makes overall.
The whole point of clustering multiple brokers together is to increase
overall message throughput via horizontal scaling. This implies increasing
concurrency. However, sharing state like this between brokers in a reliable
and deterministic way requires synchronization which is a key enemy of
concurrency and performance. I'll have a think about how this could
possibly be implemented without invalidating the purpose of clustering in
the first place.
In the meantime, could you elaborate on your use-case and why you're using
a cluster in the first place? I've often seen users implement clustering
without appreciating the nuanced performance considerations [1].
Justin
[1]
https://github.com/apache/activemq-artemis/blob/main/docs/user-manual/en/clusters.md#performance-considerations
On Mon, Mar 20, 2023 at 9:37 AM Shields, Paul Michael <pa...@hpe.com>
wrote:
> Hi,
>
> I have a clustered broker setup using loadbalance feature. I am having
> trouble getting MQTT retained messages feature to have the same last
> messages available on each of the brokers in my cluster. I need each
> client that connects to any of the brokers in the cluster to receive all
> the retained messages from all brokers, so they have a complete view of my
> system. I have tried this in the broker config file but it does not
> replicate all the retained messages to each broker. What other parameters
> do I need to set to get all retained messages to any connecting client? Any
> help greatly appreciated.
>
> <address-settings>
> <!--default for catch all-->
> <address-setting match="#">
> <redistribution-delay>0</redistribution-delay>
> <dead-letter-address>DLQ</dead-letter-address>
> <expiry-address>ExpiryQueue</expiry-address>
> <redelivery-delay>0</redelivery-delay>
> <auto-create-queues>true</auto-create-queues>
> <auto-create-addresses>true</auto-create-addresses>
> <auto-delete-queues>false</auto-delete-queues>
> <auto-delete-addresses>false</auto-delete-addresses>
> </address-setting>
> </address-settings>
>
> Best Regards,
> Paul Shields
>
Re: MQTT retained messages and a Clustered Broker
Posted by Justin Bertram <jb...@apache.org>.
This functionality isn't supported, and while it may be technically
feasible to implement I'm not sure how much sense it makes overall.
The whole point of clustering multiple brokers together is to increase
overall message throughput via horizontal scaling. This implies increasing
concurrency. However, sharing state like this between brokers in a reliable
and deterministic way requires synchronization which is a key enemy of
concurrency and performance. I'll have a think about how this could
possibly be implemented without invalidating the purpose of clustering in
the first place.
In the meantime, could you elaborate on your use-case and why you're using
a cluster in the first place? I've often seen users implement clustering
without appreciating the nuanced performance considerations [1].
Justin
[1]
https://github.com/apache/activemq-artemis/blob/main/docs/user-manual/en/clusters.md#performance-considerations
On Mon, Mar 20, 2023 at 9:37 AM Shields, Paul Michael <pa...@hpe.com>
wrote:
> Hi,
>
> I have a clustered broker setup using loadbalance feature. I am having
> trouble getting MQTT retained messages feature to have the same last
> messages available on each of the brokers in my cluster. I need each
> client that connects to any of the brokers in the cluster to receive all
> the retained messages from all brokers, so they have a complete view of my
> system. I have tried this in the broker config file but it does not
> replicate all the retained messages to each broker. What other parameters
> do I need to set to get all retained messages to any connecting client? Any
> help greatly appreciated.
>
> <address-settings>
> <!--default for catch all-->
> <address-setting match="#">
> <redistribution-delay>0</redistribution-delay>
> <dead-letter-address>DLQ</dead-letter-address>
> <expiry-address>ExpiryQueue</expiry-address>
> <redelivery-delay>0</redelivery-delay>
> <auto-create-queues>true</auto-create-queues>
> <auto-create-addresses>true</auto-create-addresses>
> <auto-delete-queues>false</auto-delete-queues>
> <auto-delete-addresses>false</auto-delete-addresses>
> </address-setting>
> </address-settings>
>
> Best Regards,
> Paul Shields
>