[GitHub] activemq-artemis issue #2392: ARTEMIS-2100 address routing-type overridden o...
Github user franz1981 commented on the issue: https://github.com/apache/activemq-artemis/pull/2392 @mtaylor I've addressed the requests you've made and added another test to cover the case where the queue is being created too :+1: ---
[GitHub] activemq-artemis issue #2392: ARTEMIS-2100 address routing-type overridden o...
Github user mtaylor commented on the issue: https://github.com/apache/activemq-artemis/pull/2392 @grs These are bugs in the code vs fundamental issues with the underlying model. We should get these fixed. I don't think these points affect the current PR. ---
[GitHub] activemq-artemis issue #2392: ARTEMIS-2100 address routing-type overridden o...
Github user grs commented on the issue: https://github.com/apache/activemq-artemis/pull/2392 Yes, I am sure iof all these points. ---
[GitHub] activemq-artemis issue #2392: ARTEMIS-2100 address routing-type overridden o...
Github user mtaylor commented on the issue: https://github.com/apache/activemq-artemis/pull/2392 > If the queue and topic with the same name/address were independent, then clients explicitly selecting one or the other would not see each others messages. Messages from a sender with capability 'queue' would not be seen by subscribers with capability 'topic'. That is not how it behaves though. Messages from all senders go to all bound queues. Are you sure this is the case? If it does behave in this way then it's a bug and we've broken JMS semantics. > > Two further separate points: > > (1) If the address already exists with multicast, and an amqp receiver attaches with capability 'queue' (i.e. anycast), the address is not modified and the queue is not created. The receiver is detached with an error that queue support is not configured. (To me that is sensible behaviour). However a sender requesting the same thing results in the address being changed and a queue being created. That seems inconsistent at best. Again, I don't think this is the case, but if you've experienced this with AMQP then it's clearly a bug and we should get it fixed. > > (2) Once a sender has forced a pre-defined address to support anycast, a receiver using a fully qualified queue name - myaddress::mysubscription - will get an error unless they request 'topic' capability though surely this form of address is entirely clear on what is required. I don't think I get this one. The FQQN bit is meant to bypass all checks and connect directly to the queue regardless of it's routing type. ---
[GitHub] activemq-artemis issue #2392: ARTEMIS-2100 address routing-type overridden o...
Github user grs commented on the issue: https://github.com/apache/activemq-artemis/pull/2392 If the queue and topic with the same name/address were independent, then clients explicitly selecting one or the other would not see each others messages. Messages from a sender with capability 'queue' would not be seen by subscribers with capability 'topic'. That is not how it behaves though. Messages from all senders go to all bound queues. Two further separate points: (1) If the address already exists with multicast, and an amqp receiver attaches with capability 'queue' (i.e. anycast), the address is not modified and the queue is not created. The receiver is detached with an error that queue support is not configured. (To me that is sensible behaviour). However a sender requesting the same thing results in the address being changed and a queue being created. That seems inconsistent at best. (2) Once a sender has forced a pre-defined address to support anycast, a receiver using a fully qualified queue name - myaddress::mysubscription - will get an error unless they request 'topic' capability though surely this form of address is entirely clear on what is required. ---
[GitHub] activemq-artemis issue #2392: ARTEMIS-2100 address routing-type overridden o...
Github user mtaylor commented on the issue: https://github.com/apache/activemq-artemis/pull/2392 > > With AMQP raw, there is no such thing as a routing type (this is a broker concept). Therefore messages sent via AMQP to an address should be routed to any routing type currently configured on that address. If an address has a single routing type configured e.g. Multicast, the message should be routed there, it should not create a new routing type with Anycast, which is what is happening here. > > agreed > > > Artemis also implements the JMS AMQP extension, which enables additional functionality, one of which is the ability to define a sender destination type, i.e. Queue or Topic. These map to Address Anycast and Multicast respectively. In this case (with auto-create disabled), if an AMQP client using this extension e.g. QPID JMS client, sends explicitly sends to Anycast, but only a Multicast address exists, then an error should be returned. > > With auto-create enabled for both addresses and queues, the behaviour would be different, an Anycast address would be created and no error thrown. > > This would make sense if anycast and multicast addresses (i.e. queue and topic) were entirely independent. They are not though. I am not sure what you mean by entirely independent. Can you elaborate. ---
[GitHub] activemq-artemis issue #2392: ARTEMIS-2100 address routing-type overridden o...
Github user grs commented on the issue: https://github.com/apache/activemq-artemis/pull/2392 > With AMQP raw, there is no such thing as a routing type (this is a broker concept). Therefore messages sent via AMQP to an address should be routed to any routing type currently configured on that address. If an address has a single routing type configured e.g. Multicast, the message should be routed there, it should not create a new routing type with Anycast, which is what is happening here. agreed > Artemis also implements the JMS AMQP extension, which enables additional functionality, one of which is the ability to define a sender destination type, i.e. Queue or Topic. These map to Address Anycast and Multicast respectively. In this case (with auto-create disabled), if an AMQP client using this extension e.g. QPID JMS client, sends explicitly sends to Anycast, but only a Multicast address exists, then an error should be returned. > > With auto-create enabled for both addresses and queues, the behaviour would be different, an Anycast address would be created and no error thrown. This would make sense if anycast and multicast addresses (i.e. queue and topic) were entirely independent. They are not though. ---
[GitHub] activemq-artemis issue #2392: ARTEMIS-2100 address routing-type overridden o...
Github user mtaylor commented on the issue: https://github.com/apache/activemq-artemis/pull/2392 There are two things at play here. AMQP raw protocol and extensions to AMQP that are broker specific. With AMQP raw, there is no such thing as a routing type (this is a broker concept). Therefore messages sent via AMQP to an address should be routed to any routing type currently configured on that address. If an address has a single routing type configured e.g. Multicast, the message should be routed there, it should not create a new routing type with Anycast, which is what is happening here. Artemis also implements the JMS AMQP extension, which enables additional functionality, one of which is the ability to define a sender destination type, i.e. Queue or Topic. These map to Address Anycast and Multicast respectively. In this case (with auto-create disabled), if an AMQP client using this extension e.g. QPID JMS client, sends explicitly sends to Anycast, but only a Multicast address exists, then an error should be returned. With auto-create enabled for both addresses and queues, the behaviour would be different, an Anycast address would be created and no error thrown. There is a special case here, when using the AMQP protocol raw (no extensions), so not specifying the routing type, and using auto create addresses. If the AMQP client sends to an address that does not exist, the broker has no way of know what type of routing type to create. In this case, the default routing type setting on the address setting is used. There's another case, which I think is what is happening here. If there exists a Mutlicast address the AMQP client raw sends here and the default routing type is Anycast with auto-create enabled. Instead of routing the message to the pre-existing routing type, it is instead trying to auto-create a new one. ---
[GitHub] activemq-artemis issue #2392: ARTEMIS-2100 address routing-type overridden o...
Github user grs commented on the issue: https://github.com/apache/activemq-artemis/pull/2392 I am talking only about the AMQP support. It is inconsistent. It does not as you say 'honour the sender'. It effectively forces the behaviour of anycast on all subsequent clients, unless every sender explicitly requests multicast. Dynamic creation of an address should only apply if the address does not exist, hence the word 'create'. Current behaviour is wrong and not what is documented. And I have never said an address cannot be both anycast and multicast, though the documentation explicitly describes this as an antipattern. For AMQP however the current behaviour means it cannot be both. Once a multicast address is recreated by the broker with anycast added, its use for multicast receivers is broken, though receivers connected before that change will continue to receive in multicast which does not honour the senders wishes. Nor is the senders wish honoured if it chooses multicast after that. ---
[GitHub] activemq-artemis issue #2392: ARTEMIS-2100 address routing-type overridden o...
Github user michaelandrepearce commented on the issue: https://github.com/apache/activemq-artemis/pull/2392 Disagree AMQP is just a protocol. A broker is just another client. There is nothing to say an address cannot be both anycast and multicast. And as such if you have left the setting to allow dynamic creation on the broker then youre allowing if the type is not currently on the address for that to be created is valid. If you dont want that simply disable the ability to create queues dynamically broker side ---
[GitHub] activemq-artemis issue #2392: ARTEMIS-2100 address routing-type overridden o...
Github user grs commented on the issue: https://github.com/apache/activemq-artemis/pull/2392 @michaelandrepearce re: "if producer explicitly sets a routing type, it must be honoured", I'm not sure what you mean there. At least from AMQP, the routing types is a property of the address, not the sender. That is it affects the behaviour of that address for all clients using it. Let's say I create an address with --no-anycast and --multicast, bind a named durable subscription queue to it, create a receiver on that named subscription queue, and two further receivers. If I know create a sender and request the 'queue' capability' (or don't request any capability), the definition of the address is changed and a queue with the same name as the address is created. However the messages from that sender are still enqueued onto each of the queues currently bound to the address (as well as the automatically created queue with the same name as the address, which now accumulates messages sent to that address not only by senders explicitly requesting anycast behaviour, but also those from senders declaring multicast behaviour). I.e. they are *not* actually being routed with anycast semantics. If my receiver to the named subscription queue exists and reconnects, it now gets an error from the broker 'Incorrect Routing Type for queue, expecting: ANYCAST' To me this seems pretty broken behaviour. ---
[GitHub] activemq-artemis issue #2392: ARTEMIS-2100 address routing-type overridden o...
Github user michaelandrepearce commented on the issue: https://github.com/apache/activemq-artemis/pull/2392 @grs On 2. I disagree if producer explicitly sets a routing type, it must be honoured. Rr defaults these only should be used if producer does not explicitly set. @franz1981 your newer implementation looks better, in that it only sets the type if not explicitly set. +1 ---
[GitHub] activemq-artemis issue #2392: ARTEMIS-2100 address routing-type overridden o...
Github user franz1981 commented on the issue: https://github.com/apache/activemq-artemis/pull/2392 @michaelandrepearce I think to have misread the issue: the current behaviour is not bad, just is not taking in consideration the already existing address routingType(s) and just choosing the default one when no specific routingType is being requested...I will soon push a commit with a different way to address it ---
[GitHub] activemq-artemis issue #2392: ARTEMIS-2100 address routing-type overridden o...
Github user grs commented on the issue: https://github.com/apache/activemq-artemis/pull/2392 Two points: 1) in my case, accessing over AMQP, the sender is *not* defining any routing type 2) I would not expect a sender requesting a routing type explicitly to redefine a statically defined address i.e. if address pre-exists and has routing types only multicast, a sender attempting to request anycast should be informed that their intentions do not match the pre-configured semantics (of course if the address does not exist then it can be defined according to the senders desires providing auto-creation of the address is allowed). ---
[GitHub] activemq-artemis issue #2392: ARTEMIS-2100 address routing-type overridden o...
Github user michaelandrepearce commented on the issue: https://github.com/apache/activemq-artemis/pull/2392 Point here is if the sender has specifically defined that has to be honoured. ---
[GitHub] activemq-artemis issue #2392: ARTEMIS-2100 address routing-type overridden o...
Github user grs commented on the issue: https://github.com/apache/activemq-artemis/pull/2392 @michaelandrepearce @franz1981 the issue is that if an address is defined to be multicast only, then a sender to it over AMQP causes the address to be redefined as multicast and anycast *and* a queue is created with the same name as the address, meaning that all other use of that address over AMQP now uses the queue. What I want is the ability to define an address that reliably behaves as a topic. ---
[GitHub] activemq-artemis issue #2392: ARTEMIS-2100 address routing-type overridden o...
Github user franz1981 commented on the issue: https://github.com/apache/activemq-artemis/pull/2392 @michaelandrepearce I understand your point here, just I'm not sure is only a matter of flexibility here, but more of user expectations and I admit that it makes this a lot more subjective to be judged. The point of the issue is that if an address already exists, but without any queue on it, which routing type configuration will take precendence while creating a new one? For some users It could be the default routing type specified on the addresses settings, while for others the ones defined in the already existing address. I admit that I'm more of the idea that the latter is matching most user expectations, but is just a personal taste. ---
[GitHub] activemq-artemis issue #2392: ARTEMIS-2100 address routing-type overridden o...
Github user michaelandrepearce commented on the issue: https://github.com/apache/activemq-artemis/pull/2392 @franz1981, i dont follow this, its seems to break some of the flexibility, e.g. if the sender sends to address as multicast then a multicast queue should be created if no queue exits and message sent to. It would also be valid for the same address for a producer to send to the address as anycast, and then it should honor that and if a queue does not exist matching the name create a queue as anycast. ---
[GitHub] activemq-artemis issue #2392: ARTEMIS-2100 address routing-type overridden o...
Github user franz1981 commented on the issue: https://github.com/apache/activemq-artemis/pull/2392 @jbertram I need to run the whole test suite on this first, but feel free to review it given that you're the last one that has worked near this same code :+1: ---
