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" <jbert...@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 <paul.shie...@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
>
