Hey @mystarrocks - thanks for the question! You are correct on the following
“withSubsriptions” is the programmatic equivalent of adding topic subscriptions to a queue in the event broker administratively As long as the queue is configured to have the “non-owner permission” property to modify topics as per Aaron’s comment and the screenshot below
To answer your question regarding the different queues I have put a sample code in python to check it out. Note that since the behaviour of the PubSub+ Messaging API for Java and Python is similar, you will get the same behaviour with the new Java API as well
Build a receiver1 and bind it to the queue_name
persistent_receiver: PersistentMessageReceiver = messaging_service.create_persistent_message_receiver_builder()\ .with_subscriptions([TopicSubscription.of("topic1/>")])\ .build(queue) persistent_receiver.start() # Callback for received messages on receiver 1 persistent_receiver.receive_async(MessageHandlerImpl()) # Build a receiver2 and bind it to the same queue_name persistent_receiver2: PersistentMessageReceiver = messaging_service.create_persistent_message_receiver_builder()\ .with_subscriptions([TopicSubscription.of("topic2/>")])\ .build(queue) persistent_receiver2.start() # Callback for received messages on receiver 2 persistent_receiver2.receive_async(MessageHandlerImpl2())
and I have defined queue in three different ways:
queue = Queue.durable_exclusive_queue(“durable-exclusive-queue”) : Since the queue is a durable exclusive queue, when I publish a message on either topic1/test/etc or topic2/test/etc only receiver 1 will receive the message. queue = Queue.durable_non_exclusive_queue(“durable-non-exclusive-queue”) : messages will be received by the two receivers in a round robin behaviour queue = Queue.non_durable_exclusive_queue(“non-durable-queue”) : This will in fact result in an error! Take a guess why and what the exception is. spoiler below ? The exception raised is {‘caller_description’: 'flow topic add sub ', ‘return_code’: ‘Fail’, ‘sub_code’: ‘SOLCLIENT_SUBCODE_MAX_CLIENTS_FOR_QUEUE’, ‘error_info_sub_code’: 63, ‘error_info_contents’: ‘Max clients exceeded for queue’} and reason being is you can only have one non durable queue per client Note: Assuming the queues already exist on the broker.
Hope this explanation helps!
And P.S, I reallly like your handbag analogy ?