When creating a topic subscription, she has a specific subscription name. Any consumer who then begins to request messages for this subscription name will compete for messages on this subscription. If you want independent applications to receive each instance of a message sent on a topic, each of them will have to create its own subscription on this topic. You can almost view each subscription as a queue for yourself, which is submitted by topic.
The example I will give relates to college. The topic is “New Student,” and every department in the college wants a copy of the message for the new student. Thus, each department will have its own subscription. There would be signatures "Music", "Billings", "Science", "Mathematics", etc. Each of them subscribed to the topic "New Student". Thus, each department receives a copy of the new student message or can filter on the things they need if they want. If the department is lagging behind in processing, they can deploy more processor instances using their subscription name, thereby increasing their throughput in theory, as more consumers compete for messages in their subscription.
So, in your example, each application will need to either create its own subscription, or assign a unique subscription to start pulling from the moment it starts. Please note that if you allow the lifetime of the application to choose the validity period of the subscription (which means that you create a subscription when you start the application and destroy it when you close the application), you need to know that if there are no active subscribers, messages sent to the topic will be simple lost. However, you can create a trick for the entire subscription that only receives messages that are not delivered to any other subscription. It really depends on what you are trying to accomplish.
Mikewo
source share