🎄 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.
How is the number of connections counted for licences?
Let's say I have:
- 1 topic "p_topic"
- 10 consumers queues from "p_topic" (one queue per consumer) "consumer1_queue", "consumer2_queue", etc.
- 1 common queue (not from "p_topic") "common_queue"
The scenario I have is:
- 10 consumers generally go about their processing by consuming from own individual queues. For example, Consumer1 will consume from consumer1_queue; Consumer2 will consume from consumer2_queue; etc.
- All consumers also access the common queue "common_queue" for placing an event message meeting certain conditions.
Under this scenario, I understand there are 10 connections for 10 consumers consuming from own queues. Do we also have additional 10 connections for all 10 consumers often connecting to the common queue?
Answers
-
Hi there @beautwaves_solace , welcome to the Community..! 🎉
So, just off the bat, the number of "connections" a broker is limited to is the number of TCP connections. Each app typically has just one TCP connection to the broker, on which they can send receive messages to lots of topics or lots of queues. So it should just be 10 if you have 10 apps.
But some points on Solace terminology… I can tell you're new to Solace:
- Queue's don't "connect" or "bind" to a topic object (there are no "topic objects" in Solace)… queues can have topic subscriptions to attract messages published on matching topics (topics are just metadata within each message… each could be unique). For example, my queue
q1could have a subscription forpayments/*/new/>, and this would match messages published to topics:payments/bankA/new/cust123payments/bankB/new/custxyz- But not:
payments/bankA/cancel/cust123hr/bankB/new/cust123/policy
- To publish to a queue, an application doesn't have to "connect" to it… queues are the guaranteed storage for an associated consumer, to ensure messages don't get lost/dropped when they're slow or offline. Publishers just publish to whatever they want (topics or queues). That said: it's our best practice to always publish to topics (and have the required topic subscriptions on the queues) vs. publishing directly to queues… this is required for more complext routing rules and broker topolgies (e.g. event mesh).
- So the "common queue" would have some subscription on it
notice/>and any of the applications could publish to a topic that starts withnotice/…and it would land in that queue.
- So the "common queue" would have some subscription on it
Hope that helps! For more details on topics + subs in Soalce check out this video: https://www.youtube.com/watch?v=PP1nNlgERQI
0 - Queue's don't "connect" or "bind" to a topic object (there are no "topic objects" in Solace)… queues can have topic subscriptions to attract messages published on matching topics (topics are just metadata within each message… each could be unique). For example, my queue
-
Thanks @Aaron , sorry, forgot to mention that consumer queues have own subscriptions from the topic. that was kinda implied.
Eahc app has a connection to solace to consume from its own main queue. but it also needs to connect to the common queue. So doesn't it count as 2 connections or still 1?
0 -
1 connection per app. 👍🏼
But: are the apps sending or receiving from the common queue? If publishing to it, they don't "connect" to it… queues belong to consumers. If they're receiving from it, then the queue would have to be non-exclusive and the messages would be round-robined between them.
0 -
thanks @Aaron . the connection to the common queue is to browse the contents and to publish to it. there is a separate consumer of the "common_queue".
0
