[ARTEMIS-550] fix up test to validate CORE and implement FQQN check b…

[gtully]

…efore core auto createQueue call

[michaelandrepearce]

Is this related to Virtual Topics support for OpenWire? My concern here is, i request a composite address on a JMS Queue, it should be ANYCAST routing.

[gtully]

it is, at least the use case in the test. It may be that some FQQN scenarios are not applicable to CORE.
I am not sure how to determine the routingTypeToUse if both the address and subscription queue need to be created.
Is there a way to know this is a fanout consumer queue/subscription queue rather than a simple ANYCAST address.
On the server in the openwire case there is a binding query such the address provides this information but I did not want to go down the route of another round trip.

[gtully]

The original test case that I added to, had both artemis and openwire jms clients in the mix, a parameterised test. It may be that the vt use case needs to be constrained to openwire because I think your expectation is correct. I guess in the case that the address already existed I may be able to find the routing type there.
But when both address and queue need to be created core would be out of luck.

[michaelandrepearce]

So if this is related to virtual topics why complicate things for the Core JMS client and introduce such problems it has JMS 2.0 spec as such shared durable subscribers, which is the spec equiv of such feature.

[graben]

Sorry, that's not correct vt and shared subscriptions are only similar but not equal. Shared subscriptions still need connections to have a clientid. Therefor those connections are bounded to a special use case. VTs has queue semantic. No "special" connections are needed. Such pooling of connections for almost everything sending/consuming/... is possible. Artemis still leaks such a feature on its core protocol.

[graben]

Look at my test case in JIRA ARTEMIS-550 and you'll see that there is still a problem concerning usage of FQQN via core protocol.

[michaelandrepearce]

I don’t see how that’s breaking, it’s been clear virtual topics as it is in activemq5 isn’t going to be ported as is to the Core JMS 2.0 layer, as use cases will be covered either with JMS 2.0 spec or FQQN (note FQQN != virtual topic).

As noted here your use case is covered by jms shared subscriptions.

This PR atm breaks the documented address model to JMS mapping’s that exists. That a JMS queue maps onto Anycast Address and a JMS topic maps onto an Multicast Address, all FQQN does is give a fully qualified queue name, it doesnt alter or define if it should be anycast of multicast, that is taken from if the destination provided is JMSQueue or JMSTopic.

@gtully
The only two ways id see this cleanly working is:

1. some new optional pre-fix support was added to FQQN naming convention to add the ability to define / override if multicast or anycast (as FQQN is multi protocol this should be protocol / api agnostic), thus not affecting current but allowing a JMSQueue to create a multicast address via FQQN. Though still i think we have to be honest here, that if the use case is covered with JMS 2.0 is there a real need to complicate things more at risk of having more corner cases that can break.

2. The other is to create a new packet request and response and server side service to match the address and get the address settings, and then set to the default routing type, if its a fqqn.
   This would be a new packet, this would need to be back/forwards compatible e.g. the client should not make this service call if it connects to an older broker, and simply keep the existing default of ANYCAST.
   I guess also this should behave the same for either JMS Topic of JMS Queue's that if FQQN then it does the same.

What can't happen is to break the default and released behaviours (not without a major version bump anyhow).

I understand ensuring the support of Virtual on openwire where JMS 1.1 so JMS Shared Subscriber doesn't exits, but thats all managed within the openwire protocol manager essentially mapping those concepts all over to core server side.

[mattrpav]

@michaelandrepearce I shared some use cases and scenarios regarding 5.x virtual topics on 550. JMS 2.0 SharedDurable subscriptions is only one use case that virtual topics help with. However, there are several that JMS 2.0 SDS won’t cover that 5.x virtual topics do. Additionally, other brokers have these features, so I believe they are “messaging patterns” vs “ActiveMQ 5.x-only” thing.

Check it out, and let me know if you want to hop on irc or a chat to go review it.

At any rate, I think Artemis would benefit from supporting virtual topics (or whatever new name is more suitable)

[michaelandrepearce]

@mattrpav im on IRC. fyi im not saying all use cases are solved by SDC, but in this case it was. We should be looking to map use cases / functionality over, not lifting and shifting virt topics as is.

[gtully]

@michaelandrepearce I agree with you, I will close out this PR.
The discussion is the valuable bit.
For this use case, SDS is the answer.
For the more general CORE FQQN scenario, using a prefix with a FQQN would be the other approach. It probably should support the prefix notation via the acceptor.
multicast://VirtualTopic.Orders::Consumer.A
This says, create me a sub queue called Consumer.A`` that is bound using multicastrouting to addressVirtualTopic.Orders```.

[michaelandrepearce]

@mattrpav i pinged on IRC but no response.

From the JIRA i see you raised three points.

Consumption is in a different destination altogether

As noted already a core queue is used for delivery either sharing a core queue (as like a JMS Queue, or JMS 2.0 Shared subscription) or having a core queue per consumer (as like JMS Topic consumer - non shared).

Consumption is handled by a queue-- which supports wider range of consuming options-- exclusive consumer, etc.

In Artemis a jms 2.0 shared subscription is a queue (note this is part of the core model) on this core queues are possible to set this up with max consumers = 1 to represent an exclusive consumer.

Client-consumers drive the behavior without the need for server-side configuration

Exactly the point of JMS 2.0 Topics, here you can send to a topic, and now you can get either queue like consuming semantics by using Shared Durable Subscription, or you can have JMS 1.1 pub sub semantic using standard Topic Consumer.

On that note, i think if anything more is needed the use case needs to be clear, because it could just be a mis-understanding of what features are there already, like above that there was an assumption that shared subscriptions client id was mandatory causing some issues, but in-fact it isn't and thus actually did meet that use case need. Atm all the ones raised are covered.

Btw i am aware of Cloned Subscriptions feature in IBM that allowed similar back in JMS 1.1 days, once JMS 2.0 came out, and their product supported it, they have this in their docs since. (note this is freely available in their open doc's)

Deciding between shared or cloned subscriptions
When you are determining whether to use shared or cloned subscriptions, consider the benefits of both. Where possible use shared subscriptions as it is specification defined behavior, rather than an IBM® extension.

Shared Subscriptions	Cloned Subscriptions
Shared subscriptions are a standard part of the JMS 2.0 specification.	Cloned subscriptions are an IBM MQ specific extension.
Shared subscriptions are created by using explicit API method calls.	Cloned subscriptions are controlled administratively at the ConnectionFactory level.
Shared subscriptions can be durable or nondurable.	Cloned subscriptions can only be durable.
Shared subscriptions are explicitly created on an individual subscription basis.	Cloned subscriptions are used for any durable subscription under a connection for which the function is enabled.
If a subscription is created as shared it cannot later be changed to unshared, or vice versa.	A subscription can be changed from cloned to uncloned each time it is reopened if the CLONESUPP property of the owning connection has changed.

https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_8.0.0/com.ibm.mq.dev.doc/q119140_.htm

As noted they're effectively pushing JMS 2.0 usage, essentially the only main advantage there using the ClonedSubscription is you can dynamically switch if the subscription from shared to non shared. JMS 2.0 in all other cases seems to cover off the cloned usage's if not giving more flexibility / control.

[michaelandrepearce]

If it helps so here is the conceptual logical model of VT in 5.x:

And here is the conceptual model of how JMS 2.0 SharedDurableConsumer maps into Core Address model (not setting clientID)

If you note in this logical model, essentially the VT is the Address (its multicast), its where messages are being sent to, and then the queues are.....queues, which get routed to.

I don't see much difference now.

[mattrpav]

@michaelandrepearce the IBM MQ scenario I was referring to was the ability to use a named queue to back a topic subscription, not cloned subscriptions-- this provides the separation of producers from consumers in terms of "its a different destination". This enables better wild card management for permissions and other access features to destinations. ie.. topic://ORDERING.** and queue://BILLING.**

I agree JMS 2.0 topic subscriptions solve the "same broker" and "same destination" use case for application-side ability to dynamically add additional consumers to a message flow without broker config or existing producer and consumer(s) impacts.

Note: on the exclusive consumer part, it sounds like Artemis has a gap vs 5.x in that the exclusive consumer config is server-side only (separate issues raised as [ARTEMIS-853] and [ARTEMIS-856]).

The key feature in the broker-to-broker message scenarios is that the publishing destination is different than the consuming destination(s). In ActiveMQ 5.x, this allows for two important multi-broker messaging patterns, as well as enable the network of broker destination filtering (include / exclude), client permissions and destination policy mapping via wild card syntax sugar for administrators. See attached graphics

Multi-broker Use Case 1:

Multi-broker Use Case 2:

[gtully]

Hope we don't lose the pictures, but this PR as it stands is too simplistic and the use case is already covered by a shared durable sub.
the prefixed fqqn will be the way to go if we need to improve in this area.
https://activemq.apache.org/artemis/docs/2.3.0/address-model.html#configuring-a-prefix-to-connect-to-a-specific-routing-type

thanks for the feedback :-)

[michaelandrepearce]

@gtully agreed.

I think it be great if @mattrpav for the use cases we think we can't cover today, theyre detailed each in a JIRA, this way we can tackle one by one, or if they are possible today, then we can create Documents in how.

[mattrpav]

Will do