Christopher do you have a list of missing notifications, is it mainly the
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 <
> 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
> > 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
> > 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
> > > use
> > > > all the time.
> > > >
> > > > I dug into this and it looks like the reason is because Artemis
> > > > 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
> > > 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
> > > > 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.
> > > >
> > >