🎄 Happy Holidays! 🥳

Most of Solace is closed December 24–January 1 so our employees can spend time with their families. We will re-open Thursday, January 2, 2024. Please expect slower response times during this period and open a support ticket for anything needing immediate assistance.

Happy Holidays!

Please note: most of Solace is closed December 25–January 2, and will re-open Tuesday, January 3, 2023.

PERSISTENT Messaging in an Event Mesh

achakour
achakour Member Posts: 1

Hello Team,

I've stumbled upon this discussion where @TomF mentioned a feature that would automatically abstract persistent message consumption from location in an Event mesh. I couldn't find anything in the documentation regarding this feature. Could you please point me to the right direction ?

To give you some context for my request, I want to horizontally scale my broker using DMR. For DIRECT messages, it would work perfectly, but for PERSISTENT messaging, I don't find a good way to configure my queues other than manually splitting them across the brokers, and try to match each consumer to the specific broker that contains its queues.

Thank you

Tagged:

Comments

  • Aaron
    Aaron Member, Administrator, Moderator, Employee Posts: 644 admin

    Hi @achakour, welcome to the Community! Nothing like that currently exists in the product. I'm guessing Tom is talking about some way to administratively copy/move queues for a persistent consumer to a different broker. That's the main issue with persistent consumers and a distributed mesh of brokers…. they have to connect back to where their queues are. Some may ask why Solace doesn't have the ability to "tunnel" a queue from one broker to another: this capability and architecture is fraught with complexity and scaling issues… it doesn't work at scale.

    Note that this is partially solved for some use cases, such as IOT at scale e.g. connected cars… where you may have millions of MQTT connections coming into a bunch of Solace brokers. Working with F5 or other load-balancing technologies, it's possible to have a "sticky load-balancing" capability where a persistent MQTT QoS1 consumer will be able to "back to where they were" based on a session ID, token, or something.

    TL/DR: your current method of "manually splitting" (albeit you could do with monitoring and scripting) is still the best/only way to do this right now.

  • TomF
    TomF Member, Employee Posts: 412 Solace Employee

    +1 to Aaron's comment here!