[GitHub] activemq-artemis issue #2392: ARTEMIS-2100 address routing-type overridden o...

2018-10-29 Thread franz1981
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...

2018-10-29 Thread mtaylor
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...

2018-10-26 Thread grs
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...

2018-10-26 Thread mtaylor
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...

2018-10-26 Thread grs
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...

2018-10-26 Thread mtaylor
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...

2018-10-26 Thread grs
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...

2018-10-26 Thread mtaylor
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...

2018-10-26 Thread grs
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...

2018-10-26 Thread michaelandrepearce
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...

2018-10-25 Thread grs
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...

2018-10-25 Thread michaelandrepearce
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...

2018-10-25 Thread franz1981
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...

2018-10-25 Thread grs
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...

2018-10-25 Thread michaelandrepearce
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...

2018-10-25 Thread grs
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...

2018-10-25 Thread franz1981
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...

2018-10-24 Thread michaelandrepearce
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...

2018-10-24 Thread franz1981
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: 


---