🎄 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.
Ensure only one publisher for a queue?
Answers
-
Hi @Harry R,
Looks like this slipped through the cracks. Did you figure it out?
In general, if there are no upstream events and these apps purely publishers then I think that leader election project is likely the right approach for this scenario. If there are upstream events that trigger the publishing then use an exclusive queue deliver the upstream events so they always go to one instance.
0 -
Hi @marc, thanks for the reply.
Unfortunately not yet. The issue with the leader election option is that the instances have knowledge of each other which makes scaling complicated.
I have two other ideas, one is to somehow delete all duplicates within a queue however I haven't been able to find any Solace functionality for this → do you know if this is possible (I have only found for preventing receiving duplicated messages)?
The other is to lock my database row when the instances try to access and send row info to the queue but I have not tried this yet.1 -
Hi @Harry R,
From the Solace broker perspective the messages would be coming from different apps w/ different message IDs, and our brokers don't look at the payload, so there isn't really a way for the broker itself to detect duplicates from a business logic perspective. I think your 3 options are
1) don't publish duplicates on the provider side…this is the leader election option. Note that by using that
spring-solace-leader-election
project I do not believe your instances need to know about each other or how many other instances there are. They just have to be able to connect to the broker and make decisions based on whether their flow is active on the exclusive queue.2) make sure your consumers can handle duplicates, which you want to do anyway with guaranteed messaging b/c it's guaranteed at least once delivery (not exactly once), or
3) you have a processor in the middle that receives the messages and republishes to another topic while filtering out duplicates.
Hope that helps some!
1