How is the number of connections counted for licences?

beautwaves_solace
beautwaves_solace Member Posts: 5 ✭
in General Discussions #1

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

  • Aaron
    Aaron Member, Administrator, Moderator, Employee Posts: 595 admin
    edited August 29 #2

    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 q1 could have a subscription for payments/*/new/>, and this would match messages published to topics:
      • payments/bankA/new/cust123
      • payments/bankB/new/custxyz
      • But not:
      • payments/bankA/cancel/cust123
      • hr/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 with notice/… and it would land in that queue.

    Hope that helps! For more details on topics + subs in Soalce check out this video: https://www.youtube.com/watch?v=PP1nNlgERQI

  • beautwaves_solace
    beautwaves_solace Member Posts: 5 ✭
    #3

    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?

  • Aaron
    Aaron Member, Administrator, Moderator, Employee Posts: 595 admin
    #4

    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.

  • beautwaves_solace
    beautwaves_solace Member Posts: 5 ✭
    #5

    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".

Categories

This Month's Leaders

This Week's Leaders