Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 16811200B9B for ; Wed, 12 Oct 2016 18:37:22 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 14F97160AD4; Wed, 12 Oct 2016 16:37:22 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 31062160ACA for ; Wed, 12 Oct 2016 18:37:21 +0200 (CEST) Received: (qmail 28939 invoked by uid 500); 12 Oct 2016 16:37:20 -0000 Mailing-List: contact dev-help@activemq.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@activemq.apache.org Delivered-To: mailing list dev@activemq.apache.org Received: (qmail 28918 invoked by uid 99); 12 Oct 2016 16:37:20 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 12 Oct 2016 16:37:20 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id 9A7661A0505 for ; Wed, 12 Oct 2016 16:37:19 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 2.379 X-Spam-Level: ** X-Spam-Status: No, score=2.379 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd2-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id 87S0GQkg8hNx for ; Wed, 12 Oct 2016 16:37:16 +0000 (UTC) Received: from mail-yw0-f170.google.com (mail-yw0-f170.google.com [209.85.161.170]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id ECE325FB68 for ; Wed, 12 Oct 2016 16:37:15 +0000 (UTC) Received: by mail-yw0-f170.google.com with SMTP id u124so36389202ywg.3 for ; Wed, 12 Oct 2016 09:37:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=q5ZFyaf26/tdIpks/Jb5aCIFxIUmQB9+pF8SjrDgYZ4=; b=jMqWEvHNXFzQ8HAmRkgNArymB1xP9hBoclAGozz9PXMIDgn/3EgxO/LCIOo/gaA2mk 4RM02tcFgsJBmDbdg9O23e4ksoD0NLyWBYJoD6OVwMjRPD+g5WCSiVDd/pl+uc4+3enG vU5XWROUgI3lQMvi6zh/ZGfkoEZyQgTQy7AIQM1sUmIUm/ARtddrZs19Q6Wi3KerJNzE 72mxzw5YBfop2jnE8FJVOfZpwmiXagAuVBzWIBQbBd7jRyWHeKGNSa++WBnpt/JtAmcG ozNW/BU0TULYLZg7zCKre+77J78YlusVWz/GcSkIwWiLUPxPMIDWIXKCKk4QzG/ndawD aeWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=q5ZFyaf26/tdIpks/Jb5aCIFxIUmQB9+pF8SjrDgYZ4=; b=F++u6YmErOrMOEmjnTTXShCrfUn/hro4wmus97cy24nF80roU7XtzioHqWsnoVtauK pLUBkna1dP77SzdXW6mVmX4ghUtsFrjAcpBwBc+i/EDMbwB0t3I0BoaAhNGvhNIV3sJu s7pGcticS8NREkIwICKFK6Wju1+KOeSvtNt2TKyTDyT+8c1/hmzh/PZ2cvGFb4RlO/0q kIfacvOnsN6osostKP19ZZKWsfK9xaRv+OrSDKzcT1mdptCQ97Fp6YoDRhY6ZI48k+e3 sTuF8nXqc+66MVt81UgIPmfo8EsJFjA0pmshcpDLgnIPGhbFgM77oewwBhBqA9TEhENc s2Sg== X-Gm-Message-State: AA6/9Rm/+Wy1Z8hks2kSQ2lSNoLW6OykQQCou4QRii+rN3/q++bSkqer//AaBJCVfbf4SCAWrkWTKmzO22eH2Q== X-Received: by 10.13.205.198 with SMTP id p189mr1712617ywd.337.1476290188147; Wed, 12 Oct 2016 09:36:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.12.68 with HTTP; Wed, 12 Oct 2016 09:35:57 -0700 (PDT) In-Reply-To: References: From: Christopher Shannon Date: Wed, 12 Oct 2016 12:35:57 -0400 Message-ID: Subject: Re: [DISCUSS] Artemis missing advisories and producer tracking To: dev@activemq.apache.org Content-Type: multipart/alternative; boundary=001a114da656401713053ead98b1 archived-at: Wed, 12 Oct 2016 16:37:22 -0000 --001a114da656401713053ead98b1 Content-Type: text/plain; charset=UTF-8 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 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 > > 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 > 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. > > > > > > > > > > > > > > > > > > > > > > > > > > > > --001a114da656401713053ead98b1--