+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