I've been keeping an eye on ARTEMIS-780 and I think this is going to be a really good improvement and should help making things a bit easier in terms of moving any features from 5.x that we want to move. For example, I put in JIRAs to migrate over 5.x style advisories but I am purposefully holding off because this change should help make it easier to do that.
Also, +1 for bumping the version to 2.0 after this is completed. This is a major enough architecture change that I think it would be a good idea to bump the major version. On Thu, Nov 17, 2016 at 5:49 AM, Martyn Taylor <[email protected]> wrote: > This is great feedback Matt, thanks. I have a couple of questions/comments > below: > > On Wed, Nov 16, 2016 at 6:23 PM, Matt Pavlovich <[email protected]> > wrote: > > > Hi Martin- > > > > Glad to see this area getting dedicated attention. A couple things I > > didn't see covered in the doc or the JIRA comments. (I'll be adding to > the > > JIRA comments as well.) > > > > Items: > > > > 0. Pre-configuring destinations is a big brain drain, so anything that > can > > be client-driven is a win. Also, protocol specific handlers could perform > > the admin operations on-demand. > > > > For example: session.createDurableSubscriber(...) The JMS handler > > create the subscription on the behalf of the client. > > > Yes I agree. We need to ensure we can both ways of defining the endpoint > semantics, i.e. allow clients to request endpoint requirements and also > have broker side configuration drive endpoint behaviour, ideally using the > same underlying mechanism. > > > > > 1. Separate topic and queue namespaces.. in JMS topic:///foo != > > queue:///foo. The addressing will need some sort of way to separate the > two > > during naming collisions. > > > Just so I understand exactly what you are saying here. You're saying that > a client sends to "foo" and a consumer received messages sent to "foo". In > order for the consumer to consume from "foo" it passes in either "foo", > "queue:///foo" or "topic:///foo" which determines how the messages are > propagated to the client? "foo" means let the broker decide, > "queue:///foo" and "topic:///foo" mean let the client decide. In addition > to these two approaches, it may be that the protocol itself wants to > decide. MQTT for example, always requires a subscription. > > One way to do this, not straying too far from the original proposal, would > be to make the address uniqueness a combination of the routing type and the > address name. This would allow something like: > > <address name="foo" routingType="anycast"> > <address name="foo" routingType="multicast"> > > We'd need to ensure there is a precedent set for times when a subscriber > just subscribes to "foo". I'd say it makes sense for "multicast" to take > precedence in this case. > > I think it probably makes the most sense to have the following precedence > for the deciding party: > > 1. Broker > 2. Address prefixing/name scheme > 3. Protocol > > I think the prefix also needs to be configurable, but "queue:///" > "topic:///" seems like a sensible default. > > > > > 2. In ActiveMQ 5.x, AMQP and STOMP handled the addressing by using > > queue:/// and topic:/// prefixes. I don't think that is necessarily a bad > > thing, but something to consider b/c we need to support #1 > > > +1 > > > > > 3. As far as destination behaviors, how about using uri parameters to > pass > > provider (Artemis) specific settings on-the-fly? > > > > For example: in AMPQ the address could be > > topic:///foo?type=nonSharedNonDurable etc.. same for MQTT, STOMP, etc. > > > > There is precedence in using uri parameters to configure the > > Destination in JMS as well. IBM MQ has session.createQueue("My.Queue? > > targetClient=1") > > > > Note: AMQP supports options as well, so that could be used as well. > > However, uri's tend to be better for externalizing configuration > management. > > > I think supporting both options, uri and protocol specific parameters is > useful. Rather than "nonSharedDurable" I think I'd prefer to map these > things onto address properties. For example: > > "topic://foo?maxConsumers=1" > > Where the "topic:///" prefix is configurable. This is essentially a non > shared, durable subscription. > > > > > 4. Destination name separation b/w protocol handlers. STOMP and MQTT > like > > "/" and JMS likes "." as destination name separators. Is there any > thought > > to having a native destination name separator and then have > > protocol-specific convertors? > > > This is how it works right now. We have a native path separator which is > ".". Protocol handlers map subscription addresses down to this. This does > mean that to define a multicast address for MQTT, you would need to do: > > "foo.bar" (vs "foo/bar" which is protocol specific). > > I've also outlined in the proposal a goal to allow these path separators to > be configurable. So you can specify pathSeparator="/", "." which would > mean that you can configure "foo/bar" or "foo.bar" they'd both act in the > same way. > > > > > 5. Fully qualified destination names that include a broker name. Other > > providers support fully-qualified destination names in JMS following the > > format: queue://$brokerName/$queueName. Adding this would go a long way > > to supporting migration of current applications without having to change > > client-code. > > > This is a little differently to how clustering currently works, I think we > need to give this one some more thought. Right now queues are clustered > automatically (well providing you enable the correct address namespace for > the cluster connection). If you have a client listening on broker2 and a > producer from broker1, the messages will get propagated across the cluster. > > You may have already explained this to me in the past, but can you give me > an example use case of when this might be necessary. > > > > > Note: This would probably impact cluster handling as well, so perhaps > > in phase 1 there is just a placeholder for supporting a broker name in > the > > future? > > > > -Matt > > Thanks > Martyn > > > > > > > On 11/16/16 10:16 AM, Martyn Taylor wrote: > > > >> All, > >> > >> Some discussion has happened around this topic already, but I wanted to > >> ensure that everyone here, who have not been following the > >> JIRA/ARTEMIS-780 > >> branch has a chance for input and to digest the information in this > >> proposal. > >> > >> In order to understand the motivators outlined here, you first need to > >> understand how the existing addressing model works in Artemis. For those > >> of > >> you who are not familiar with how things currently work, I’ve added a > >> document to the ARTEMIS-780 JIRA in the attachments section, that gives > an > >> overview of the existing model and some more detail / examples of the > >> proposal: *https://issues.apache.org/jira/browse/ARTEMIS-780 > >> <https://issues.apache.org/jira/browse/ARTEMIS-780>* > >> > >> To summarise here, the Artemis routing/addressing model has some > >> restrictions: > >> > >> 1. It’s not possible with core (and therefore across all protocols) to > >> define ,at the broker side, semantics about addresses. i.e. whether an > >> address behaves as a “point to point” or “publish subscribe” end point > >> > >> 2. For JMS destinations additional configuration and objects were added > to > >> the broker, that rely on name-spacing to add semantics to addresses i.e. > >> “jms.topic.” “jms.queue.” A couple of issues with this: > >> > >> 1. > >> > >> This only works for JMS and no other protocols > >> 2. > >> > >> Name-spacing causes issues for cross protocol communication > >> 3. > >> > >> It means there’s two ways of doing things, 1 for JMS and 1 for > >> everything else. > >> > >> 3. The JMS and Core destination definitions do not have enough > information > >> to define more intricate behaviours. Such as whether an address should > >> behave like a “shared subscription” or similar to a “volatile > >> subscription” > >> where clients don’t get messages missed when they are offline. > >> > >> 4. Some protocols (AMQP is a good example) don’t have enough information > >> in > >> their frames for the broker to determine how to behave for certain > >> endpoints and rely on broker side configuration (or provider specific > >> parameters). > >> > >> Proposal > >> > >> What I’d like to do (and what I’ve proposed in ARTEMIS-780) is to get > rid > >> of the JMS specific components and create a single unified mechanism for > >> configuring all types of endpoints across all protocols to define: > >> > >> - > >> > >> Point to point (queue) > >> - > >> > >> Shared Durable Subscriptions > >> - > >> > >> Shared Non Durable Subscriptions > >> - > >> > >> Non Shared durable subscriptions > >> - > >> > >> > >> Non Shared Non durable subscriptions > >> > >> To do this, the idea is to create a new “Address” > configuration/management > >> object, that has certain properties such as a routing type which > >> represents > >> how messages are routed to queues with this address. > >> > >> When a request for subscription is received by Artemis, the relevant > piece > >> can just look up the address and check it’s properties to determine how > to > >> behave (or if an address doesn’t exist) then default to our existing > >> behaviour. For those interested in the details of how this might work > I’ve > >> outlined some specific examples in the document on the JIRA. > >> > >> What are the user impacts: > >> > >> 1. Configuration would need to be revised in order to expose the new > >> addressing object. I propose that we either continue supporting the old > >> schema for a while and/or provide a tool to migrate the configuration > >> schema. > >> > >> 2. Some new management operations would need to be added to expose the > new > >> objects. > >> > >> 3. The JMS configuration and management objects would become obsolete, > and > >> would need removing. The Broker side JMS resources were only a thin > facade > >> to allow some JMS specific behaviour for managing destinations and for > >> things like registering objects in JNDI. > >> > >> Broker side JNDI was removed in Artemis 1.0 in order to align with > >> ActiveMQ > >> 5.x style of client side JNDI. These JMS pieces and their management > >> objects don't really do much, creating connection factories for instance > >> offers no functionality right now. Going forward, users should be able > to > >> use the core management API to do everything. > >> > >> 4. All client applications should behave exactly as they were before. > The > >> proposal is for adding features to the core model, not removing any. > For > >> things like the Artemis JMS client which relied on name-spaces, they’ll > be > >> a mechanism to define a name-spaced address and a mechanism to switch > back > >> on name-spaces in the client. > >> > >> 5. Given some of the API changes and removal of the JMS specific pieces. > >> This would likely warrant a major bump. i.e. Artemis 2.0.0. > >> > >> Whilst I’ve been looking at this, it’s become apparent, that the JMS > >> pieces > >> have leaked into lots of areas of the code base, which does mean we’d > need > >> to do a fair amount refactoring to move these bits to the new model. > >> > >> In my opinion this proposal can only be a good thing. It creates a > single > >> place (core) where all addressing objects are configured and managed and > >> allows all protocol managers to plug into the same mechanism. It solves > >> some of the cross protocol JMS → other protocols that we’ve seen users > >> struggle with, but still offers a way to support all the old behaviour > in > >> client applications. > >> > >> What are others thoughts on this? Any suggestions, comments or concerns? > >> > >> Regards > >> Martyn > >> > >> > > >
