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 <mtay...@redhat.com> wrote:

> On Wed, Oct 12, 2016 at 4:17 PM, Christopher Shannon <
> christopher.l.shan...@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 <mtay...@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.shan...@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 <jgo...@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.shan...@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.shan...@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.
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Reply via email to