How is the number of connections counted for partitioned queue?
I am using partitioned queues.
Let's say I have:
- 1 topic "p_topic"
- 10 consumers queues from "p_topic" (one queue per consumer) "consumer1_partitioned_queue", "consumer2_partitioned_queue", etc.
- Each queue is partitioned into 4 by a key.
The scenario I have is:
- Mule Consumer1 API, which uses Mule JMS connector with number of consumer set to 4.
- It consumes from its queue "consumer1_partitioned_queue" and all 4 partition has an associated Partition Client coming from 4 threads of the same Consumer1 API.
Under this scenario,
Is the number of connection still 10 - even though there are 40 Partition Clients? or is connection based on number of Clients, in which case it would be 40?
Best Answer
Answers
-
So you have 10 partitioned queues, each with 4 partitions? This will be counted as 44 guaranteed endpoints in the broker (I think dev brokers max out at 100?) (or 1000 with the increased scaling tier?)
For the number of connections, it will kind of depend on the Mule JMS connector works, how it handles multiple consumers… it's possible in Solace APIs to have one application with one connection to the broker and connected to the same queue 4 times (these would be called egress flows in Solace-speak), and maybe each flow processed by a different thread in the application (so: 1 connection). OR: you could have one app with 4 connections, and each connection has one flow to the queue (4 connections). Or the more "microservice" approach: 4 apps, each binding to the queue once (4 connections). In all these cases, you'd have 4 egress flows.
So the answer could be 10 or 40, and kind of depends how the connector works. Should be pretty easy to test and verify..?
1 -
@Aaron I think the first case is what I am talking about, one API connecting to solace same queue 4 times and sounds like 1 connection.
Where can I see "number of connections" on solace cluster?
0
