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 <[email protected]> wrote: > On Wed, Oct 12, 2016 at 4:17 PM, Christopher Shannon < > [email protected]> 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 <[email protected]> > > 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 < > > > [email protected]> 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 <[email protected]> > 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 < > > > > > [email protected]> 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 < > > > > > > [email protected]> 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. > > > > > > > > > > > > > > > > > > > > > > > > > > > >
