Artemis: AMQP create queue based on FQQN

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Artemis: AMQP create queue based on FQQN

Havret
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?
Reply | Threaded
Open this post in threaded view
|

Re: Artemis: AMQP create queue based on FQQN

Havret
I've look at the source code, and it seems to be doable to implement auto
creation of queues based on FQQN? If you don't mind I would like to give it
a try.

On Sun, Dec 29, 2019 at 10:46 PM Krzysztof <[hidden email]> 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?
>
Reply | Threaded
Open this post in threaded view
|

Re: Artemis: AMQP create queue based on FQQN

clebertsuconic
I'm still a bit slow after my vacations :)


What this means? an expression to create the queue names on DLQs? I
guess I'm very slow still :)

I've tried something similar in the past but I couldn't find a way
without breaking the APi too much. If you found a way.. perhaps we can
review how you would implement it?

On Wed, Jan 8, 2020 at 5:36 PM Krzysztof <[hidden email]> wrote:

>
> I've look at the source code, and it seems to be doable to implement auto
> creation of queues based on FQQN? If you don't mind I would like to give it
> a try.
>
> On Sun, Dec 29, 2019 at 10:46 PM Krzysztof <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Artemis: AMQP create queue based on FQQN

jbertram
In reply to this post by Havret
What protocol is the client going to use?


Justin

On Sun, Dec 29, 2019 at 3:53 PM Krzysztof <[hidden email]> 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?
>
Reply | Threaded
Open this post in threaded view
|

Re: Artemis: AMQP create queue based on FQQN

Havret
@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 <[hidden email]> wrote:

> What protocol is the client going to use?
>
>
> Justin
>
> On Sun, Dec 29, 2019 at 3:53 PM Krzysztof <[hidden email]> 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?
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Artemis: AMQP create queue based on FQQN

jbertram
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 <[hidden email]> 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 <[hidden email]> wrote:
>
> > What protocol is the client going to use?
> >
> >
> > Justin
> >
> > On Sun, Dec 29, 2019 at 3:53 PM Krzysztof <[hidden email]> 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?
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Artemis: AMQP create queue based on FQQN

clebertsuconic
I really like the .NET AMQP API that Microsoft itself develops.

although I don't spend my day to day in .NET, it was simple to use it
when I needed it.

On Thu, Jan 9, 2020 at 6:04 PM Justin Bertram <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
> >
> > > What protocol is the client going to use?
> > >
> > >
> > > Justin
> > >
> > > On Sun, Dec 29, 2019 at 3:53 PM Krzysztof <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Artemis: AMQP create queue based on FQQN

Havret
In reply to this post by jbertram
@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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> wrote:
> >
> > > What protocol is the client going to use?
> > >
> > >
> > > Justin
> > >
> > > On Sun, Dec 29, 2019 at 3:53 PM Krzysztof <[hidden email]> 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?
> > > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Artemis: AMQP create queue based on FQQN

clebertsuconic
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> > wrote:
> > >
> > > > What protocol is the client going to use?
> > > >
> > > >
> > > > Justin
> > > >
> > > > On Sun, Dec 29, 2019 at 3:53 PM Krzysztof <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Artemis: AMQP create queue based on FQQN

Martyn Taylor-2
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 <[hidden email]>
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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]> 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 <[hidden email]>
> > > wrote:
> > > >
> > > > > What protocol is the client going to use?
> > > > >
> > > > >
> > > > > Justin
> > > > >
> > > > > On Sun, Dec 29, 2019 at 3:53 PM Krzysztof <[hidden email]>
> 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
>
Reply | Threaded
Open this post in threaded view
|

Re: Artemis: AMQP create queue based on FQQN

michael.andre.pearce
In reply to this post by Havret
KPShared durable and shared non durable is covered in JMS 2.0 api. The NMS api is meant to be a JMS equiv. As such simply we need to add those methods and other parts of JMS 2.0 to NMSNo need to make new or different apis IMHOMikeSent from my Samsung Galaxy smartphone.
-------- Original message --------From: Krzysztof <[hidden email]> Date: 09/01/2020  22:05  (GMT+00:00) To: [hidden email] Subject: Re: Artemis: AMQP create queue based on FQQN @ClebertSo the idea is to reduce the impedance mismatch between Artemis addressmodel (which is geat!) and the concepts from jms/nms (not so great, atleast 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 itsaddress, routing type (Multicast, Anycast) and queue name. It would be niceif I could define if the subscription is shared and durable as well. Ifthis particular queue doesn't exist, currently the exception is thrown. Iwould like to change this behavior, to create the queue dynamically. Thesame way as queues are created for jms 2.0 subscriptions. Sample api wouldlook like thisvar consumer = await connection.CreateConsumerAsync("test-consumer",RoutingType.Anycast, "q1");@JustinI'm using AMQP. The very early POC is herehttps://github.com/Havret/ActiveMQ.NetOn Thu, Jan 9, 2020 at 3:16 AM Justin Bertram <[hidden email]> wrote:> What protocol is the client going to use?>>> Justin>> On Sun, Dec 29, 2019 at 3:53 PM Krzysztof <[hidden email]> 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?> >>
Reply | Threaded
Open this post in threaded view
|

Re: Artemis: AMQP create queue based on FQQN

michael.andre.pearce
In reply to this post by jbertram
I agree .As per other mail rather than trying to make some new api or something esoteric.It be much better to simply update NMS api to 2.0 e.g. add shared durable and shared non durable consumer methods to api. Along with others.This then give you what you need KPNMS is meant to be a port of the JMS api in .NET And with those methods in 2.0 youd be able to do what you needSent from my Samsung Galaxy smartphone.
-------- Original message --------From: Justin Bertram <[hidden email]> Date: 09/01/2020  23:04  (GMT+00:00) To: [hidden email] Subject: Re: Artemis: AMQP create queue based on FQQN This seems a little strange to me.The power of JMS is that it is broker agnostic. It's just an API of fairlygeneric 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, wasmeant to mitigate that weakness by porting the same basic API to .Net (andthe same goes for CMS with C++). The goal was to have an API for which anybroker could implement a client. Early implementations could talk toActiveMQ (via the OpenWire protocol), Tibco EMS, and IBM WebSphereMQ. Oneimplementation was even apparently built on Microsoft's MSMQ API. There wasalso a STOMP implementation and then later an AMQP one. The benefit ofthese two is that they used standard communication protocols and thereforecould be used with any broker which supported that protocol. So, forexample, 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 anAPI on top of it that mirrors the ActiveMQ Artemis address model. Thisruins the flexibility that AMQP provides and marries client applications toa single broker. Furthermore, AMQP doesn't "know" about routing types,addresses, and queues. It has different concepts which we *map* onto theArtemis addressing model in the broker.The Artemis addressing model is low-level in order to be able to supportall kinds of different protocols which each have their ownsimilar-but-slightly-different models.Why don't you just implement the core protocol in .Net? It appears to methat if you use AMQP you're going to have to somehow shoehorn in Artemisaddressing model concepts on the client and then interpret those on thebroker. 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 usedthe core protocol then you'd have access to everything.Aside from that, what's wrong with the APIs for other AMQP or STOMP clientsfor .Net?JustinOn Thu, Jan 9, 2020 at 4:12 PM Krzysztof <[hidden email]> 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 <[hidden email]> wrote:>> > What protocol is the client going to use?> >> >> > Justin> >> > On Sun, Dec 29, 2019 at 3:53 PM Krzysztof <[hidden email]> 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?> > >> >>