You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by Christopher Shannon <ch...@gmail.com> on 2016/10/12 12:32:57 UTC
[DISCUSS] Artemis missing advisories and producer tracking
In general it would be nice if all of the current advisories that are
supported in 5.x could eventually be supported in Artemis as well. As I
was looking at Artemis's notifications to see what currently existed one
thing I noticed was that there is a lack of producer notifications. Having
an advisory sent when a producer is created is something that I know I use
all the time.
I dug into this and it looks like the reason is because Artemis doesn't
actually track a producer until the first message is sent. In fact there's
no notion of a producer on the core wire format at all (there's no packet
type for it).
I realize that many protocols don't have the notion of a producer...In 5.x
this is handled by just creating ProducerInfo objects on first connection
when a protocol doesn't support it (ie Stomp, etc). However, the JMS API
does have a specific call to create a producer so I find it useful to get
an advisory message and to track when producers come online even if not
every protocol supports this.
So I guess I wanted to see what people thought about adding a notification
for producers and also trying to fill in the gaps for the rest of the
advisory topics that are missing.
Re: [DISCUSS] Artemis missing advisories and producer tracking
Posted by Christopher Shannon <ch...@gmail.com>.
I went ahead and created https://issues.apache.org/jira/browse/ARTEMIS-796
and the discussion can be continued on there for how to go about this.
On Wed, Oct 12, 2016 at 11:46 AM, Martyn Taylor <mt...@redhat.com> wrote:
> On Wed, Oct 12, 2016 at 4:17 PM, Christopher Shannon <
> christopher.l.shannon@gmail.com> wrote:
>
> > The advisories are all listed here:
> > http://activemq.apache.org/advisory-message.html
>
> Thanks. One difficulty here would be adding all the "topic" advisories,
> since we don't really have the concept of a "topic" in Artemis Core. I am
> hoping to change this with:
> https://issues.apache.org/jira/browse/ARTEMIS-780. Which would expose
> pub/sub at the Artemis Core level. This should facilitate any equivalent
> pub/sub (topic) advisories listed here.
>
> > The only ones currently
> > that I saw that were being sent from the OpenWireProtocolManager were for
> > created/destroyed destinations and new connections.
> >
> > Obviously not all the advisories are currently possible to add but
> > eventually would be nice to support them. In 5.x there's a plugin to
> handle
> > the advisories but in Artemis maybe we could piggy back on the
> > NotificationListener interface that is used for notifications to handle
> > publishing advisory messages. There's also the notion of replaying
> > advisories for new connections which may not currently exist. Ie when a
> > new subscriber comes online to the consumer advisory topic we should
> replay
> > all the consumers messages.
>
>
> > For MQTT and STOMP, I agree that it may not necessarily make sense to
> track
> > the producers since they don't exist in the protocol (or maybe we send it
> > lazy on the first message send) But for the CORE protocol I would think
> it
>
> would be pretty straightforward to add a new packet type that a client
> > could send and it could be tracked. I can work on a PR for it if everyone
> > agrees it makes sense to track it.
>
> I don't think I am quite sold on the lazy producer notifications idea :P.
> But we can get into the details on the JIRA / PR.
>
> >
> > I don't currently have a JIRA created as I wanted to get a discussion
> going
> > first. Not sure if it makes sense to create individual JIRAs or create
> one
> > JIRA for advisory support with sub tasks.
>
> I tend to go with a single JIRA with subtasks for things like this.
>
> >
>
>
> >
> > On Wed, Oct 12, 2016 at 10:54 AM, Martyn Taylor <mt...@redhat.com>
> > wrote:
> >
> > > Christopher do you have a list of missing notifications, is it mainly
> the
> > > producer notifications?
> > >
> > > I'm all for adding these where they make sense, but there maybe places
> > > where the notifications don't quite make sense to do at the Artemis
> Core
> > > level. I suspect then, that we'll need to do some notifications on a
> per
> > > protocol basis. In the producer case, protocols handlers layer the
> > > functionality on top of the CORE model, the concept of a broker side
> > > producer is not something we have in Artemis Core. OpenWire has a
> > > ProducerInfo packet and AMQP a "Sender LinkAttach", in these cases the
> > > "producer" state is kept in the protocol module itself, MQTT, STOMP and
> > > CORE don't have such things and I'm not sure a notification makes sense
> > to
> > > send notifications for these.
> > >
> > > We probably need to address these one by one. Do you have a JIRA where
> > we
> > > can track this?
> > >
> > > On Wed, Oct 12, 2016 at 3:31 PM, Christopher Shannon <
> > > christopher.l.shannon@gmail.com> wrote:
> > >
> > > > I would say that for JMS (and certainly OpenWire) a producer should
> be
> > > > considered created when making that create producer call on a JMS
> > client.
> > > > At least with OpenWire that ProducerInfo object is sent immediately
> on
> > > > creation and is tracked.
> > > >
> > > > However for other protocols that isn't the case and lazy notification
> > > might
> > > > make more sense but it would be different behavior than 5.x which may
> > or
> > > > may not be ok. So really we need to decide what our strategy is and
> > > > whether or not we try to make advisory processing uniform across all
> > > > protocols like 5.x or if we leave something like when a producer
> > advisory
> > > > is sent up to each individual protocol.
> > > >
> > > >
> > > > On Wed, Oct 12, 2016 at 10:17 AM, Jim Gomes <jg...@apache.org>
> wrote:
> > > >
> > > > > +1 for supporting all the advisories that the current ActiveMQ 5.x
> > > > > supports.
> > > > >
> > > > > As for when the advisory message is sent for a Producer, I'm not
> sure
> > > > there
> > > > > is a specific guarantee about that. If a Producer is 'created',
> but a
> > > > > message is never sent, was it actually created? I'm not necessarily
> > > > opposed
> > > > > to the lazy notification strategy.
> > > > >
> > > > >
> > > > > On Wed, Oct 12, 2016, 6:48 AM Christopher Shannon <
> > > > > christopher.l.shannon@gmail.com> wrote:
> > > > >
> > > > > > Also as a follow up, I noticed that the OpenWireProtocalManager
> > > already
> > > > > > fires a couple advisories for new connections/destinations. I
> can
> > > > > > certainly create a PR to add more advisories but I guess really
> the
> > > > > > question is whether or not we should support the advisories
> across
> > > any
> > > > > > protocol or not.
> > > > > >
> > > > > > On Wed, Oct 12, 2016 at 8:32 AM, Christopher Shannon <
> > > > > > christopher.l.shannon@gmail.com> wrote:
> > > > > >
> > > > > > > In general it would be nice if all of the current advisories
> that
> > > are
> > > > > > > supported in 5.x could eventually be supported in Artemis as
> > well.
> > > > > As I
> > > > > > > was looking at Artemis's notifications to see what currently
> > > existed
> > > > > one
> > > > > > > thing I noticed was that there is a lack of producer
> > notifications.
> > > > > > Having
> > > > > > > an advisory sent when a producer is created is something that I
> > > know
> > > > I
> > > > > > use
> > > > > > > all the time.
> > > > > > >
> > > > > > > I dug into this and it looks like the reason is because Artemis
> > > > doesn't
> > > > > > > actually track a producer until the first message is sent. In
> > fact
> > > > > > there's
> > > > > > > no notion of a producer on the core wire format at all (there's
> > no
> > > > > packet
> > > > > > > type for it).
> > > > > > >
> > > > > > > I realize that many protocols don't have the notion of a
> > > > producer...In
> > > > > > 5.x
> > > > > > > this is handled by just creating ProducerInfo objects on first
> > > > > connection
> > > > > > > when a protocol doesn't support it (ie Stomp, etc). However,
> the
> > > JMS
> > > > > API
> > > > > > > does have a specific call to create a producer so I find it
> > useful
> > > to
> > > > > get
> > > > > > > an advisory message and to track when producers come online
> even
> > if
> > > > not
> > > > > > > every protocol supports this.
> > > > > > >
> > > > > > > So I guess I wanted to see what people thought about adding a
> > > > > > notification
> > > > > > > for producers and also trying to fill in the gaps for the rest
> of
> > > the
> > > > > > > advisory topics that are missing.
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: [DISCUSS] Artemis missing advisories and producer tracking
Posted by Martyn Taylor <mt...@redhat.com>.
On Wed, Oct 12, 2016 at 4:17 PM, Christopher Shannon <
christopher.l.shannon@gmail.com> wrote:
> The advisories are all listed here:
> http://activemq.apache.org/advisory-message.html
Thanks. One difficulty here would be adding all the "topic" advisories,
since we don't really have the concept of a "topic" in Artemis Core. I am
hoping to change this with:
https://issues.apache.org/jira/browse/ARTEMIS-780. Which would expose
pub/sub at the Artemis Core level. This should facilitate any equivalent
pub/sub (topic) advisories listed here.
> The only ones currently
> that I saw that were being sent from the OpenWireProtocolManager were for
> created/destroyed destinations and new connections.
>
> Obviously not all the advisories are currently possible to add but
> eventually would be nice to support them. In 5.x there's a plugin to handle
> the advisories but in Artemis maybe we could piggy back on the
> NotificationListener interface that is used for notifications to handle
> publishing advisory messages. There's also the notion of replaying
> advisories for new connections which may not currently exist. Ie when a
> new subscriber comes online to the consumer advisory topic we should replay
> all the consumers messages.
> For MQTT and STOMP, I agree that it may not necessarily make sense to track
> the producers since they don't exist in the protocol (or maybe we send it
> lazy on the first message send) But for the CORE protocol I would think it
would be pretty straightforward to add a new packet type that a client
> could send and it could be tracked. I can work on a PR for it if everyone
> agrees it makes sense to track it.
I don't think I am quite sold on the lazy producer notifications idea :P.
But we can get into the details on the JIRA / PR.
>
> I don't currently have a JIRA created as I wanted to get a discussion going
> first. Not sure if it makes sense to create individual JIRAs or create one
> JIRA for advisory support with sub tasks.
I tend to go with a single JIRA with subtasks for things like this.
>
>
> On Wed, Oct 12, 2016 at 10:54 AM, Martyn Taylor <mt...@redhat.com>
> wrote:
>
> > Christopher do you have a list of missing notifications, is it mainly the
> > producer notifications?
> >
> > I'm all for adding these where they make sense, but there maybe places
> > where the notifications don't quite make sense to do at the Artemis Core
> > level. I suspect then, that we'll need to do some notifications on a per
> > protocol basis. In the producer case, protocols handlers layer the
> > functionality on top of the CORE model, the concept of a broker side
> > producer is not something we have in Artemis Core. OpenWire has a
> > ProducerInfo packet and AMQP a "Sender LinkAttach", in these cases the
> > "producer" state is kept in the protocol module itself, MQTT, STOMP and
> > CORE don't have such things and I'm not sure a notification makes sense
> to
> > send notifications for these.
> >
> > We probably need to address these one by one. Do you have a JIRA where
> we
> > can track this?
> >
> > On Wed, Oct 12, 2016 at 3:31 PM, Christopher Shannon <
> > christopher.l.shannon@gmail.com> wrote:
> >
> > > I would say that for JMS (and certainly OpenWire) a producer should be
> > > considered created when making that create producer call on a JMS
> client.
> > > At least with OpenWire that ProducerInfo object is sent immediately on
> > > creation and is tracked.
> > >
> > > However for other protocols that isn't the case and lazy notification
> > might
> > > make more sense but it would be different behavior than 5.x which may
> or
> > > may not be ok. So really we need to decide what our strategy is and
> > > whether or not we try to make advisory processing uniform across all
> > > protocols like 5.x or if we leave something like when a producer
> advisory
> > > is sent up to each individual protocol.
> > >
> > >
> > > On Wed, Oct 12, 2016 at 10:17 AM, Jim Gomes <jg...@apache.org> wrote:
> > >
> > > > +1 for supporting all the advisories that the current ActiveMQ 5.x
> > > > supports.
> > > >
> > > > As for when the advisory message is sent for a Producer, I'm not sure
> > > there
> > > > is a specific guarantee about that. If a Producer is 'created', but a
> > > > message is never sent, was it actually created? I'm not necessarily
> > > opposed
> > > > to the lazy notification strategy.
> > > >
> > > >
> > > > On Wed, Oct 12, 2016, 6:48 AM Christopher Shannon <
> > > > christopher.l.shannon@gmail.com> wrote:
> > > >
> > > > > Also as a follow up, I noticed that the OpenWireProtocalManager
> > already
> > > > > fires a couple advisories for new connections/destinations. I can
> > > > > certainly create a PR to add more advisories but I guess really the
> > > > > question is whether or not we should support the advisories across
> > any
> > > > > protocol or not.
> > > > >
> > > > > On Wed, Oct 12, 2016 at 8:32 AM, Christopher Shannon <
> > > > > christopher.l.shannon@gmail.com> wrote:
> > > > >
> > > > > > In general it would be nice if all of the current advisories that
> > are
> > > > > > supported in 5.x could eventually be supported in Artemis as
> well.
> > > > As I
> > > > > > was looking at Artemis's notifications to see what currently
> > existed
> > > > one
> > > > > > thing I noticed was that there is a lack of producer
> notifications.
> > > > > Having
> > > > > > an advisory sent when a producer is created is something that I
> > know
> > > I
> > > > > use
> > > > > > all the time.
> > > > > >
> > > > > > I dug into this and it looks like the reason is because Artemis
> > > doesn't
> > > > > > actually track a producer until the first message is sent. In
> fact
> > > > > there's
> > > > > > no notion of a producer on the core wire format at all (there's
> no
> > > > packet
> > > > > > type for it).
> > > > > >
> > > > > > I realize that many protocols don't have the notion of a
> > > producer...In
> > > > > 5.x
> > > > > > this is handled by just creating ProducerInfo objects on first
> > > > connection
> > > > > > when a protocol doesn't support it (ie Stomp, etc). However, the
> > JMS
> > > > API
> > > > > > does have a specific call to create a producer so I find it
> useful
> > to
> > > > get
> > > > > > an advisory message and to track when producers come online even
> if
> > > not
> > > > > > every protocol supports this.
> > > > > >
> > > > > > So I guess I wanted to see what people thought about adding a
> > > > > notification
> > > > > > for producers and also trying to fill in the gaps for the rest of
> > the
> > > > > > advisory topics that are missing.
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: [DISCUSS] Artemis missing advisories and producer tracking
Posted by Christopher Shannon <ch...@gmail.com>.
The advisories are all listed here:
http://activemq.apache.org/advisory-message.html The only ones currently
that I saw that were being sent from the OpenWireProtocolManager were for
created/destroyed destinations and new connections.
Obviously not all the advisories are currently possible to add but
eventually would be nice to support them. In 5.x there's a plugin to handle
the advisories but in Artemis maybe we could piggy back on the
NotificationListener interface that is used for notifications to handle
publishing advisory messages. There's also the notion of replaying
advisories for new connections which may not currently exist. Ie when a
new subscriber comes online to the consumer advisory topic we should replay
all the consumers messages.
For MQTT and STOMP, I agree that it may not necessarily make sense to track
the producers since they don't exist in the protocol (or maybe we send it
lazy on the first message send) But for the CORE protocol I would think it
would be pretty straightforward to add a new packet type that a client
could send and it could be tracked. I can work on a PR for it if everyone
agrees it makes sense to track it.
I don't currently have a JIRA created as I wanted to get a discussion going
first. Not sure if it makes sense to create individual JIRAs or create one
JIRA for advisory support with sub tasks.
On Wed, Oct 12, 2016 at 10:54 AM, Martyn Taylor <mt...@redhat.com> wrote:
> Christopher do you have a list of missing notifications, is it mainly the
> producer notifications?
>
> I'm all for adding these where they make sense, but there maybe places
> where the notifications don't quite make sense to do at the Artemis Core
> level. I suspect then, that we'll need to do some notifications on a per
> protocol basis. In the producer case, protocols handlers layer the
> functionality on top of the CORE model, the concept of a broker side
> producer is not something we have in Artemis Core. OpenWire has a
> ProducerInfo packet and AMQP a "Sender LinkAttach", in these cases the
> "producer" state is kept in the protocol module itself, MQTT, STOMP and
> CORE don't have such things and I'm not sure a notification makes sense to
> send notifications for these.
>
> We probably need to address these one by one. Do you have a JIRA where we
> can track this?
>
> On Wed, Oct 12, 2016 at 3:31 PM, Christopher Shannon <
> christopher.l.shannon@gmail.com> wrote:
>
> > I would say that for JMS (and certainly OpenWire) a producer should be
> > considered created when making that create producer call on a JMS client.
> > At least with OpenWire that ProducerInfo object is sent immediately on
> > creation and is tracked.
> >
> > However for other protocols that isn't the case and lazy notification
> might
> > make more sense but it would be different behavior than 5.x which may or
> > may not be ok. So really we need to decide what our strategy is and
> > whether or not we try to make advisory processing uniform across all
> > protocols like 5.x or if we leave something like when a producer advisory
> > is sent up to each individual protocol.
> >
> >
> > On Wed, Oct 12, 2016 at 10:17 AM, Jim Gomes <jg...@apache.org> wrote:
> >
> > > +1 for supporting all the advisories that the current ActiveMQ 5.x
> > > supports.
> > >
> > > As for when the advisory message is sent for a Producer, I'm not sure
> > there
> > > is a specific guarantee about that. If a Producer is 'created', but a
> > > message is never sent, was it actually created? I'm not necessarily
> > opposed
> > > to the lazy notification strategy.
> > >
> > >
> > > On Wed, Oct 12, 2016, 6:48 AM Christopher Shannon <
> > > christopher.l.shannon@gmail.com> wrote:
> > >
> > > > Also as a follow up, I noticed that the OpenWireProtocalManager
> already
> > > > fires a couple advisories for new connections/destinations. I can
> > > > certainly create a PR to add more advisories but I guess really the
> > > > question is whether or not we should support the advisories across
> any
> > > > protocol or not.
> > > >
> > > > On Wed, Oct 12, 2016 at 8:32 AM, Christopher Shannon <
> > > > christopher.l.shannon@gmail.com> wrote:
> > > >
> > > > > In general it would be nice if all of the current advisories that
> are
> > > > > supported in 5.x could eventually be supported in Artemis as well.
> > > As I
> > > > > was looking at Artemis's notifications to see what currently
> existed
> > > one
> > > > > thing I noticed was that there is a lack of producer notifications.
> > > > Having
> > > > > an advisory sent when a producer is created is something that I
> know
> > I
> > > > use
> > > > > all the time.
> > > > >
> > > > > I dug into this and it looks like the reason is because Artemis
> > doesn't
> > > > > actually track a producer until the first message is sent. In fact
> > > > there's
> > > > > no notion of a producer on the core wire format at all (there's no
> > > packet
> > > > > type for it).
> > > > >
> > > > > I realize that many protocols don't have the notion of a
> > producer...In
> > > > 5.x
> > > > > this is handled by just creating ProducerInfo objects on first
> > > connection
> > > > > when a protocol doesn't support it (ie Stomp, etc). However, the
> JMS
> > > API
> > > > > does have a specific call to create a producer so I find it useful
> to
> > > get
> > > > > an advisory message and to track when producers come online even if
> > not
> > > > > every protocol supports this.
> > > > >
> > > > > So I guess I wanted to see what people thought about adding a
> > > > notification
> > > > > for producers and also trying to fill in the gaps for the rest of
> the
> > > > > advisory topics that are missing.
> > > > >
> > > >
> > >
> >
>
Re: [DISCUSS] Artemis missing advisories and producer tracking
Posted by Martyn Taylor <mt...@redhat.com>.
Christopher do you have a list of missing notifications, is it mainly the
producer notifications?
I'm all for adding these where they make sense, but there maybe places
where the notifications don't quite make sense to do at the Artemis Core
level. I suspect then, that we'll need to do some notifications on a per
protocol basis. In the producer case, protocols handlers layer the
functionality on top of the CORE model, the concept of a broker side
producer is not something we have in Artemis Core. OpenWire has a
ProducerInfo packet and AMQP a "Sender LinkAttach", in these cases the
"producer" state is kept in the protocol module itself, MQTT, STOMP and
CORE don't have such things and I'm not sure a notification makes sense to
send notifications for these.
We probably need to address these one by one. Do you have a JIRA where we
can track this?
On Wed, Oct 12, 2016 at 3:31 PM, Christopher Shannon <
christopher.l.shannon@gmail.com> wrote:
> I would say that for JMS (and certainly OpenWire) a producer should be
> considered created when making that create producer call on a JMS client.
> At least with OpenWire that ProducerInfo object is sent immediately on
> creation and is tracked.
>
> However for other protocols that isn't the case and lazy notification might
> make more sense but it would be different behavior than 5.x which may or
> may not be ok. So really we need to decide what our strategy is and
> whether or not we try to make advisory processing uniform across all
> protocols like 5.x or if we leave something like when a producer advisory
> is sent up to each individual protocol.
>
>
> On Wed, Oct 12, 2016 at 10:17 AM, Jim Gomes <jg...@apache.org> wrote:
>
> > +1 for supporting all the advisories that the current ActiveMQ 5.x
> > supports.
> >
> > As for when the advisory message is sent for a Producer, I'm not sure
> there
> > is a specific guarantee about that. If a Producer is 'created', but a
> > message is never sent, was it actually created? I'm not necessarily
> opposed
> > to the lazy notification strategy.
> >
> >
> > On Wed, Oct 12, 2016, 6:48 AM Christopher Shannon <
> > christopher.l.shannon@gmail.com> wrote:
> >
> > > Also as a follow up, I noticed that the OpenWireProtocalManager already
> > > fires a couple advisories for new connections/destinations. I can
> > > certainly create a PR to add more advisories but I guess really the
> > > question is whether or not we should support the advisories across any
> > > protocol or not.
> > >
> > > On Wed, Oct 12, 2016 at 8:32 AM, Christopher Shannon <
> > > christopher.l.shannon@gmail.com> wrote:
> > >
> > > > In general it would be nice if all of the current advisories that are
> > > > supported in 5.x could eventually be supported in Artemis as well.
> > As I
> > > > was looking at Artemis's notifications to see what currently existed
> > one
> > > > thing I noticed was that there is a lack of producer notifications.
> > > Having
> > > > an advisory sent when a producer is created is something that I know
> I
> > > use
> > > > all the time.
> > > >
> > > > I dug into this and it looks like the reason is because Artemis
> doesn't
> > > > actually track a producer until the first message is sent. In fact
> > > there's
> > > > no notion of a producer on the core wire format at all (there's no
> > packet
> > > > type for it).
> > > >
> > > > I realize that many protocols don't have the notion of a
> producer...In
> > > 5.x
> > > > this is handled by just creating ProducerInfo objects on first
> > connection
> > > > when a protocol doesn't support it (ie Stomp, etc). However, the JMS
> > API
> > > > does have a specific call to create a producer so I find it useful to
> > get
> > > > an advisory message and to track when producers come online even if
> not
> > > > every protocol supports this.
> > > >
> > > > So I guess I wanted to see what people thought about adding a
> > > notification
> > > > for producers and also trying to fill in the gaps for the rest of the
> > > > advisory topics that are missing.
> > > >
> > >
> >
>
Re: [DISCUSS] Artemis missing advisories and producer tracking
Posted by Christopher Shannon <ch...@gmail.com>.
I would say that for JMS (and certainly OpenWire) a producer should be
considered created when making that create producer call on a JMS client.
At least with OpenWire that ProducerInfo object is sent immediately on
creation and is tracked.
However for other protocols that isn't the case and lazy notification might
make more sense but it would be different behavior than 5.x which may or
may not be ok. So really we need to decide what our strategy is and
whether or not we try to make advisory processing uniform across all
protocols like 5.x or if we leave something like when a producer advisory
is sent up to each individual protocol.
On Wed, Oct 12, 2016 at 10:17 AM, Jim Gomes <jg...@apache.org> wrote:
> +1 for supporting all the advisories that the current ActiveMQ 5.x
> supports.
>
> As for when the advisory message is sent for a Producer, I'm not sure there
> is a specific guarantee about that. If a Producer is 'created', but a
> message is never sent, was it actually created? I'm not necessarily opposed
> to the lazy notification strategy.
>
>
> On Wed, Oct 12, 2016, 6:48 AM Christopher Shannon <
> christopher.l.shannon@gmail.com> wrote:
>
> > Also as a follow up, I noticed that the OpenWireProtocalManager already
> > fires a couple advisories for new connections/destinations. I can
> > certainly create a PR to add more advisories but I guess really the
> > question is whether or not we should support the advisories across any
> > protocol or not.
> >
> > On Wed, Oct 12, 2016 at 8:32 AM, Christopher Shannon <
> > christopher.l.shannon@gmail.com> wrote:
> >
> > > In general it would be nice if all of the current advisories that are
> > > supported in 5.x could eventually be supported in Artemis as well.
> As I
> > > was looking at Artemis's notifications to see what currently existed
> one
> > > thing I noticed was that there is a lack of producer notifications.
> > Having
> > > an advisory sent when a producer is created is something that I know I
> > use
> > > all the time.
> > >
> > > I dug into this and it looks like the reason is because Artemis doesn't
> > > actually track a producer until the first message is sent. In fact
> > there's
> > > no notion of a producer on the core wire format at all (there's no
> packet
> > > type for it).
> > >
> > > I realize that many protocols don't have the notion of a producer...In
> > 5.x
> > > this is handled by just creating ProducerInfo objects on first
> connection
> > > when a protocol doesn't support it (ie Stomp, etc). However, the JMS
> API
> > > does have a specific call to create a producer so I find it useful to
> get
> > > an advisory message and to track when producers come online even if not
> > > every protocol supports this.
> > >
> > > So I guess I wanted to see what people thought about adding a
> > notification
> > > for producers and also trying to fill in the gaps for the rest of the
> > > advisory topics that are missing.
> > >
> >
>
Re: [DISCUSS] Artemis missing advisories and producer tracking
Posted by Jim Gomes <jg...@apache.org>.
+1 for supporting all the advisories that the current ActiveMQ 5.x supports.
As for when the advisory message is sent for a Producer, I'm not sure there
is a specific guarantee about that. If a Producer is 'created', but a
message is never sent, was it actually created? I'm not necessarily opposed
to the lazy notification strategy.
On Wed, Oct 12, 2016, 6:48 AM Christopher Shannon <
christopher.l.shannon@gmail.com> wrote:
> Also as a follow up, I noticed that the OpenWireProtocalManager already
> fires a couple advisories for new connections/destinations. I can
> certainly create a PR to add more advisories but I guess really the
> question is whether or not we should support the advisories across any
> protocol or not.
>
> On Wed, Oct 12, 2016 at 8:32 AM, Christopher Shannon <
> christopher.l.shannon@gmail.com> wrote:
>
> > In general it would be nice if all of the current advisories that are
> > supported in 5.x could eventually be supported in Artemis as well. As I
> > was looking at Artemis's notifications to see what currently existed one
> > thing I noticed was that there is a lack of producer notifications.
> Having
> > an advisory sent when a producer is created is something that I know I
> use
> > all the time.
> >
> > I dug into this and it looks like the reason is because Artemis doesn't
> > actually track a producer until the first message is sent. In fact
> there's
> > no notion of a producer on the core wire format at all (there's no packet
> > type for it).
> >
> > I realize that many protocols don't have the notion of a producer...In
> 5.x
> > this is handled by just creating ProducerInfo objects on first connection
> > when a protocol doesn't support it (ie Stomp, etc). However, the JMS API
> > does have a specific call to create a producer so I find it useful to get
> > an advisory message and to track when producers come online even if not
> > every protocol supports this.
> >
> > So I guess I wanted to see what people thought about adding a
> notification
> > for producers and also trying to fill in the gaps for the rest of the
> > advisory topics that are missing.
> >
>
Re: [DISCUSS] Artemis missing advisories and producer tracking
Posted by Christopher Shannon <ch...@gmail.com>.
Also as a follow up, I noticed that the OpenWireProtocalManager already
fires a couple advisories for new connections/destinations. I can
certainly create a PR to add more advisories but I guess really the
question is whether or not we should support the advisories across any
protocol or not.
On Wed, Oct 12, 2016 at 8:32 AM, Christopher Shannon <
christopher.l.shannon@gmail.com> wrote:
> In general it would be nice if all of the current advisories that are
> supported in 5.x could eventually be supported in Artemis as well. As I
> was looking at Artemis's notifications to see what currently existed one
> thing I noticed was that there is a lack of producer notifications. Having
> an advisory sent when a producer is created is something that I know I use
> all the time.
>
> I dug into this and it looks like the reason is because Artemis doesn't
> actually track a producer until the first message is sent. In fact there's
> no notion of a producer on the core wire format at all (there's no packet
> type for it).
>
> I realize that many protocols don't have the notion of a producer...In 5.x
> this is handled by just creating ProducerInfo objects on first connection
> when a protocol doesn't support it (ie Stomp, etc). However, the JMS API
> does have a specific call to create a producer so I find it useful to get
> an advisory message and to track when producers come online even if not
> every protocol supports this.
>
> So I guess I wanted to see what people thought about adding a notification
> for producers and also trying to fill in the gaps for the rest of the
> advisory topics that are missing.
>