Consumer for a topic mapped to queue, subscribed by multiple topics.

You shouldn't try that, it's not how PubSub+ is meant to be used.

In this case, you want to have multiple queues.

• One queue for the particular topic
• One queue for the other topics (unless you need the event to be process twice for two different purpose)

General rule : it's one queue per client application, where each queue is configured as per the need of the related application.

If you have two applications that requires the same events (same topic subscriptions), you create two queues, with the same subscriptions. Messages are stored only once.

For each application (queue), you can decide if you want delayed delivery, partitioned queue, Message priority, Max Redelivery, dead message queue, Time to live, custom alert thresold etc… replay message for one application, not the other ….

Topic Endpoint are here to support the transition for an application connected to another Broker, when this application uses JMS & Durable Subscriptions, which is a less interesting version of queues.

See https://docs.solace.com/Messaging/Guaranteed-Msg/Topic-Endpoints.htm

Topic Endpoint can have only one subscription. It's really a tool used for moving application from durable subscriptions to queues with subscriptions. ⇒ Don't use Topic Endpoints ;)

Queues and subscriptions:

Let's says you've got a e-commerce order processing in place using Solace. New Orders are published on topics

ACME/orders/{countryCode}/{customerId}

Now you want to implement a loyalty program, but you'll start with France as a pilot country.

So your "LoyaltyProgram" queue would have one subscription :

ACME/orders/FR/*

Then you progressively add more countries French speaking countries:

ACME/orders/FR/*
ACME/orders/BE/*
ACME/orders/CH/*


Then you implement internationalisation :
ACME/orders/FR/*
ACME/orders/BE/*
ACME/orders/CH/*
ACME/orders/UK/*
ACME/orders/US/*
ACME/orders/IN/*

And maybe, ultimately all countries in the world
ACME/orders/*/*
or
ACME/orders/>

The important thing is that all events have same schema and schema version, so that you're sure that the application that is bound to the queue can deserialise the payload. It's a good practice to set the schema version of the event in the topic :
ACME/orders/{OrderSchemaVersion}/{countryCode}/{customerId}

And an app would be compatible with mutliple versions: (because you're a big company and have multiple application distributed around the world that are upgraded at different time)

Realtime montioring progamm
Subs:
ACME/orders/1.2.*/*/*

Loyalty program
Subs :
ACME/orders/1.2.*/*/*
ACME/orders/1.3.0/*/*

Queues subscriptions can also be updated in real time, either by the application or via the management API (SEMP).

So you could add a new application "Realtime Monitoring of sales", plug to an app that would show dynamic graphs of the ongoing sales.

This queue, would old no subscriptions if no one is watching, and when a human open this monitoring app, he would choose which countries to look at and the subscriptions would be updated in real time with the list of countries he want to see.

For example just the french speaking countries to compare their buying behavior in real time (lets says an ad is running on TV in those countries) . The human would select the FR, CH, BE countries, the underlying application would use the messaging API to update the queue subscriptions to

ACME/orders/FR/*
ACME/orders/BE/*
ACME/orders/CH/*

On logout, it would clear the subscriptions and maybe empty the queue.