My understanding was that auto-creation of FQQN queues was always an
intention but was never implemented. Enabling this in the AMQP (and other
protocols) *should* allow any JMS over AMQP clients to utilize this
feature. There may be some details here in terms of order of
precedence when using topic/queue capabilities (as defined in the JMS AMQP
mapping) and what is specified in the FQQN, but could be implemented
relatively easily.
On Fri, Jan 10, 2020 at 10:47 PM Clebert Suconic <clebert.suco...@gmail.com>
wrote:
> Up until artemis 1.x we only had the concept of address-name / queue-name.
>
> We had to add a few hacks back then during 1.x on the server
> (specially on the JMS implementation) such as queues with forced-empty
> filters to ensure we hold the existence of the address. So, the new
> address model helped to eliminate these hacks. (Damn JMS.. as it
> requires certain semantics such as knowing when an "empty" address
> does not exist.. damn topics!)
>
> Other than that the address model I think it's pretty flexible. The
> routing type exists pretty much to differentiate empty addresses.
> Again.. damn JMS! as we require that kind of thing to satisfy topics.
>
> Martyn Taylor and Justin Bertram can speak more about that as they
> wrote the changes. I had extensive conversations with them at the
> time.. but they can speak more on that.
>
>
> On Fri, Jan 10, 2020 at 4:44 PM Krzysztof <h4v...@gmail.com> wrote:
> >
> > @Justin
> >
> > In my humble opinion the greatest power of JMS is also its greatest
> > weakness, and it's not the fact that its Java based. It's the
> > specification, that enforces some serious constraints like requirement of
> > serial execution of consumer callbacks inside the same session, ability
> to
> > "recover" session on the client, enforcing transactions on all link
> actions
> > (acks and sends) inside the same session, session based acknowledgment
> etc.
> > that doesn't add much value from the user perspective, and at the same
> time
> > seriously degrade the overall implementation and usability.
> >
> > I think that from Artemis perspective there is no concept of AMQP
> > flexibility. As you pointed out, AMQP doesn't "know" anything about
> routing
> > types, addresses, and queues (actually it does know sth about addresses
> ;)
> > But at the same time it doesn't know anything about topics, queues,
> shared
> > durable subscriptions, non shared durable subscriptions, and all that
> > either. You do not map AMQP concepts onto the Artemis addressing model.
> You
> > are mapping qpid-jms implementation to Artemis addressing model. As a
> > result Artemis amqp provider is so tightly coupled to jms, that if you do
> > not know the internals of qpid-jms amqp protocol you are forced to either
> > pre-configure all of your messaging topology upfront on the broker, and
> use
> > FQQN, or you can use only some rudimentary features of the addressing
> > model.
> >
> > I don't want to implement the core protocol because there is already a
> > great low level library AmqpNetLite (it is the counterpart of proton in
> > java world) that I am using as a base for my Artemis client. I don't want
> > to reinvent the wheel. But at the same time I don't want to adapt JMS
> > addressing model and concepts because it simply doesn't feel right to me.
> > It doesn't have to be so complicated.
> >
> > I was talking with developers from my company for the last 6 months and
> > collecting feedback regarding NMS.AMQP implementation (that I was working
> > on) and they were all complaining about the API. Most of the teams ended
> up
> > creating their own abstractions on top of it, just to hide the nms bits.
> > And they haven't even seen jms 2.0 spec. I think in java world it is
> quite
> > similar (that's why there are bits like JmsTemplate,
> > SimpleListenerContainers and the like.
> >
> > I don't want to impose anything. I just think that Artemis is a great
> piece
> > of technology and it is a shame that it's so dramatically unpopular in
> .net
> > world. It deserves better. But without a decent client it's hard to hope
> > for it.
> >
> > I don't want to shoehorn anything. I think the concept of FQQN provides a
> > nice loophole for everything I need, besides maybe some minor changes
> > (creating queues if they aren't created upfront, and basically that's
> it).
> >
> > On Fri, Jan 10, 2020 at 12:04 AM Justin Bertram <jbert...@apache.org>
> wrote:
> >
> > > This seems a little strange to me.
> > >
> > > The power of JMS is that it is broker agnostic. It's just an API of
> fairly
> > > generic messaging concepts for which any broker can implement a client.
> > >
> > > The weakness of JMS is that it is Java based. NMS, as I understand it,
> was
> > > meant to mitigate that weakness by porting the same basic API to .Net
> (and
> > > the same goes for CMS with C++). The goal was to have an API for which
> any
> > > broker could implement a client. Early implementations could talk to
> > > ActiveMQ (via the OpenWire protocol), Tibco EMS, and IBM WebSphereMQ.
> One
> > > implementation was even apparently built on Microsoft's MSMQ API.
> There was
> > > also a STOMP implementation and then later an AMQP one. The benefit of
> > > these two is that they used standard communication protocols and
> therefore
> > > could be used with any broker which supported that protocol. So, for
> > > example, a messaging application using NMS AMQP could talk to RabbitMQ,
> > > Apache Qpid, ActiveMQ 5.x, or ActiveMQ Artemis.
> > >
> > > You're taking a standard communication protocol (i.e. AMQP) and
> putting an
> > > API on top of it that mirrors the ActiveMQ Artemis address model. This
> > > ruins the flexibility that AMQP provides and marries client
> applications to
> > > a single broker. Furthermore, AMQP doesn't "know" about routing types,
> > > addresses, and queues. It has different concepts which we *map* onto
> the
> > > Artemis addressing model in the broker.
> > >
> > > The Artemis addressing model is low-level in order to be able to
> support
> > > all kinds of different protocols which each have their own
> > > similar-but-slightly-different models.
> > >
> > > Why don't you just implement the core protocol in .Net? It appears to
> me
> > > that if you use AMQP you're going to have to somehow shoehorn in
> Artemis
> > > addressing model concepts on the client and then interpret those on the
> > > broker. You are certainly free to implement the client the way you
> want,
> > > but I don't think I would endorse broker changes to support it. If you
> used
> > > the core protocol then you'd have access to everything.
> > >
> > > Aside from that, what's wrong with the APIs for other AMQP or STOMP
> clients
> > > for .Net?
> > >
> > >
> > > Justin
> > >
> > > On Thu, Jan 9, 2020 at 4:12 PM Krzysztof <h4v...@gmail.com> wrote:
> > >
> > > > @Clebert
> > > > So the idea is to reduce the impedance mismatch between Artemis
> address
> > > > model (which is geat!) and the concepts from jms/nms (not so great,
> at
> > > > least for folks from .net world, who used to work with rabbit mq
> before).
> > > >
> > > > I would like to be able to create a consumer and attach it by
> defining
> > > its
> > > > address, routing type (Multicast, Anycast) and queue name. It would
> be
> > > nice
> > > > if I could define if the subscription is shared and durable as well.
> If
> > > > this particular queue doesn't exist, currently the exception is
> thrown. I
> > > > would like to change this behavior, to create the queue dynamically.
> The
> > > > same way as queues are created for jms 2.0 subscriptions. Sample api
> > > would
> > > > look like this
> > > >
> > > > var consumer = await connection.CreateConsumerAsync("test-consumer",
> > > > RoutingType.Anycast, "q1");
> > > >
> > > > @Justin
> > > > I'm using AMQP. The very early POC is here
> > > > https://github.com/Havret/ActiveMQ.Net
> > > >
> > > > On Thu, Jan 9, 2020 at 3:16 AM Justin Bertram <jbert...@apache.org>
> > > wrote:
> > > >
> > > > > What protocol is the client going to use?
> > > > >
> > > > >
> > > > > Justin
> > > > >
> > > > > On Sun, Dec 29, 2019 at 3:53 PM Krzysztof <h4v...@gmail.com>
> wrote:
> > > > >
> > > > > > I'm just wondering if it should be possible to create queue
> based on
> > > > the
> > > > > > value specified via FQQN. Currently you cannot attach to the
> queue if
> > > > it
> > > > > is
> > > > > > not pre-configured.
> > > > > >
> > > > > > I'm working on POC of .NET ActiveMQ client and I am trying to
> give
> > > the
> > > > > > potential user as flexible API as possible.
> > > > > >
> > > > > > The draft API assumes that it should be feasible to specify
> address,
> > > > > > routing type (Multicast, Anycast), queue name, durability, and
> > > whether
> > > > > the
> > > > > > queue should be shared or not.
> > > > > >
> > > > > > This way user would be able to leverage most of the Artemis
> Address
> > > > Model
> > > > > > configuration options directly from the code without
> > > pre-configuration
> > > > > > anything on the broker side.
> > > > > >
> > > > > > What do you think?
> > > > > >
> > > > >
> > > >
> > >
>
>
>
> --
> Clebert Suconic
>
