Queue behavior when subscribing to exact same sub-topic

[BobClaerhout]

Describe the bug I have another question concerning enmasse. I've already updated to version 0.26.2 to make sure I do not run into already known issues. I have some scenario's which react differently depending on how I subscribe to the topic. For these tests I create a large topic call "topic" using the web interface.

To Reproduce

1. Scenario 1
   • Situation: I subscribe with 2 subscribers to topic "topic" and send a message with address "topic".
   • Result: Both the subscribers receive the message
2. Scenario 2
   • Situation: I subscribe with 1 subscriber to topic "topic/test" and 1 subscriber to topic "topic/+" and send a message with address "topic/test"
   • Result: Both the subscribers receive the message
3. Scenario 3
   • Situation: I subscribe with 1 subscriber to topic "topic/#" and 1 subscriber to topic "topic/+" and send a message with address "topic/test"
   • Result: Both the subscribers receive the message
4. Scenario 4
   • Situation: I subscribe with 2 subscribers to topic "topic/+" and send a mesage with address "topic/test".
   • Result: only 1 of the subscribers receives the message
5. Scenario 5
   • Situation: I subscribe with 2 subscribers to topic "topic/test" and send a mesage with address "topic/test".
   • Result: only 1 of the subscribers receives the message

Expected behavior So, scenario 1, 2, 3 are all reacting similarly. But scenario 4 and 5 are completely different only because the subscribe (with wildcards) to the exact same subtopic. Is this intended behavior? In my particular case I would like to receive the message on the 2 subscribers whether they subscribe to the same topic or not doesn't matter. The address is created as a topic but acts as a queue when based on the subscription topics in my opinion.

Additional context In order for me to check whether I have to correct thoughts: when I want a particular subscription to end up in a queue and therefore only one subscriber receives the message, I should be using a subscription on a topic. Is this correct?

Additional test I also tested this in a brokered address space, seems to have the same behavior.

[vbusch]

Have been able to reproduce this with the Qpid proton client.

The issue is not reproducible with the Qpid JMS client.

[grs]

@vbusch try adding the 'topic' capability to the links when attaching. I suspect that is the difference.

[vbusch]

Modifying simple_recv.py for the capabilities works. However, if a client has already connected to 'topic/+' without passing the capabilities, you will need to delete the topic and recreate it.

Required changes: add options to the create_receiver call

event.container.create_receiver(self.url, options=CapabilityOptions())
class CapabilityOptions(ReceiverOption):
    def apply(self, receiver):
        receiver.source.capabilities.put_object(symbol("topic"))

[BobClaerhout]

So when I create a topic, it depends on the first client whether the topic will be a topic or a queue?

[vbusch]

Yes. Only the first client matters. If the first client is a sender, then the capabilities=topic will be automatically set for you. But it isn't meaningful for senders to send to a wildcard address..

[BobClaerhout]

Wouldn't it be more logical if this was determined at creation time of the topic? It is specifically asked to create a topic. Why would I want to have a queue when I ask for a topic?

[vbusch]

Yes, it would be more logical. This is being brought up as part of a larger discussion, on what the defaults should be in the broker and clients. In the mean time, we will need to ensure this is documented.

[jenmalloy]

For the documentation update, see https://github.com/EnMasseProject/enmasse/pull/2428/