From dev-return-32471-archive-asf-public=cust-asf.ponee.io@geode.apache.org Fri Nov 15 00:48:21 2019 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [207.244.88.153]) by mx-eu-01.ponee.io (Postfix) with SMTP id 37405180607 for ; Fri, 15 Nov 2019 01:48:21 +0100 (CET) Received: (qmail 6791 invoked by uid 500); 15 Nov 2019 00:48:20 -0000 Mailing-List: contact dev-help@geode.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@geode.apache.org Delivered-To: mailing list dev@geode.apache.org Received: (qmail 6779 invoked by uid 99); 15 Nov 2019 00:48:19 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 15 Nov 2019 00:48:19 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id 2F546C1C36 for ; Fri, 15 Nov 2019 00:48:19 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=6.31 tests=[HTML_MESSAGE=0.2, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=disabled Received: from mx1-ec2-va.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id oMXpCUiL64x9 for ; Fri, 15 Nov 2019 00:48:16 +0000 (UTC) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=148.163.150.38; helo=mx0a-00296801.pphosted.com; envelope-from=moleske@pivotal.io; receiver= Received: from mx0a-00296801.pphosted.com (mx0a-00296801.pphosted.com [148.163.150.38]) by mx1-ec2-va.apache.org (ASF Mail Server at mx1-ec2-va.apache.org) with ESMTPS id 71F56BC509 for ; Fri, 15 Nov 2019 00:48:16 +0000 (UTC) Received: from pps.filterd (m0114583.ppops.net [127.0.0.1]) by mx0a-00296801.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xAF0ZOh4013441 for ; Fri, 15 Nov 2019 00:48:15 GMT Received: from mail-yw1-f72.google.com (mail-yw1-f72.google.com [209.85.161.72]) by mx0a-00296801.pphosted.com with ESMTP id 2w8x26rya3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Fri, 15 Nov 2019 00:48:14 +0000 Received: by mail-yw1-f72.google.com with SMTP id t188so5446631ywc.18 for ; Thu, 14 Nov 2019 16:48:14 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=RVT+oStnXSWF4kPgVkms0WN8qbrRxuShPfT3oqw5GCA=; b=HGa9gO/swQxKZJJYeHENT4z38KMNqwQT+RZ+8TPaWKEHgBknOl0pzC7YJBJs0Srm3x ksevo241X6eaR8vjP6w9po5jrkQfThBh72xCnadPtEj7NzJJdXWg8hl1I7fWMujU3dHd 6kN1pLGocM6zHofSVtX6vNJc6i1aVDJ/SjQbEAJaBWz55KSHtXzplaZW+GBYCAZHpaRs yifzhuYItT3HCiHUg0i7OYxzD8Y7+FmEYaRih/LYlPvmckDGtQBryExqu7wDp36GeogG rZ39ylivjZnawGyF037wlnBLGsBpxTr8SQUYxRLNfdjaI7BudXvGGhZRCI0IB2Ln4scd HaIQ== X-Gm-Message-State: APjAAAV0SS7F8yhzQDKvy+GvUqjSNhH9CEpEX41FEm1bSgHb12rbemxY vWBl89nN8grzEiu9zTuO+v5n0rVuRVW7IYUvrNF0cBHR5zTvldJgee1b3RGXqMiY2vayatM+2sL LjdmRgD/khPZqSTvijNI1MrcFmq6fIwx+EiSas+Cw+LX+19doioxKpVk= X-Received: by 2002:a25:75d7:: with SMTP id q206mr9978323ybc.177.1573778893662; Thu, 14 Nov 2019 16:48:13 -0800 (PST) X-Google-Smtp-Source: APXvYqyknbe2d0MGkJaLeSK6heoyDbZY3YGsi0aAjnVj+UYkhNegfUjKOibAofvrsTJh26Co7O2hSLA1qeQkSpHUUNU= X-Received: by 2002:a25:75d7:: with SMTP id q206mr9978292ybc.177.1573778893258; Thu, 14 Nov 2019 16:48:13 -0800 (PST) MIME-Version: 1.0 References: <1de61b7e-6823-d197-5353-6a453a0d5176@apache.com> In-Reply-To: From: Michael Oleske Date: Thu, 14 Nov 2019 16:48:02 -0800 Message-ID: Subject: Re: Odg: gateway sender queue To: dev@geode.apache.org Content-Type: multipart/alternative; boundary="000000000000e361ba059757f3e5" X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-11-14_07:2019-11-14,2019-11-14 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 adultscore=0 clxscore=1015 mlxscore=0 malwarescore=0 phishscore=0 bulkscore=0 suspectscore=0 spamscore=0 lowpriorityscore=0 priorityscore=1501 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1911150001 --000000000000e361ba059757f3e5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > vsd stat in the gfs file > Just here to say consider using a meter instead of stat as documented in https://cwiki.apache.org/confluence/display/GEODE/How+to+add+a+Meter if more than a log message is warrented. -michael On Thu, Nov 14, 2019 at 11:29 AM Nabarun Nag wrote: > +1 to Dan's suggestion > > What about a log and a vsd stat in the gfs file which tells us if any > cleanQueue commands were executed. > > > Regards > Nabarun Nag > > On Thu, Nov 14, 2019 at 10:27 AM Udo Kohlmeyer wrote: > > > In addition... making is default has bigger consequences that we have > > not thought about.. > > > > e.g if you purge an existing queue on start up.. is this the start up o= f > > the server node / GS Queue? Given that we have shared-nothing > > architecture, purging *should* only be local and not cluster-wide... I'= d > > be interested and see a proposal on this feature. > > > > --Udo > > > > On 11/14/19 10:24 AM, Jason Huynh wrote: > > > +1 to Dan's suggestion > > > > > > On Thu, Nov 14, 2019 at 9:52 AM Dan Smith wrote: > > > > > >> I'm ok with adding a --cleanQueue option. > > >> > > >> However, I don't think it should default to be true, since that woul= d > be > > >> changing the behavior of the existing command. It should default to > > false. > > >> > > >> -Dan > > >> > > >> On Thu, Nov 14, 2019 at 9:28 AM Xiaojian Zhou > wrote: > > >> > > >>> The --cleanQueue option is a similar idea as Barry's "DeadLetter" > > spike. > > >> I > > >>> remembered that we decided not to do it. > > >>> > > >>> > > >>> On Wed, Nov 13, 2019 at 11:41 PM Mario Ivanac > > > >>> wrote: > > >>> > > >>>> Hi, > > >>>> > > >>>> just to remind you on last question: > > >>>> > > >>>> what is your opinion on adding additional option in gfsh command > > >> "start > > >>>> gateway sender" > > >>>> to control clearing of existing queues --cleanQueues. > > >>>> > > >>>> This option will indicate, when gateway sender is started, should = we > > >>>> discard/clean existing queue, or should we use existing queue. > > >>>> By default it will be to discard/clean existing queue. > > >>>> > > >>>> Best Regards, > > >>>> Mario > > >>>> ________________________________ > > >>>> =C5=A0alje: Mario Ivanac > > >>>> Poslano: 8. studenog 2019. 13:00 > > >>>> Prima: dev@geode.apache.org > > >>>> Predmet: Odg: gateway sender queue > > >>>> > > >>>> Hi all, > > >>>> > > >>>> one more clarification regarding 3rd question: > > >>>> > > >>>> "* Could we add extra option in gfsh command "start gateway > sender" > > >>>> that allows to control queues reset (for instance > > --cleanQueues)" > > >>>> > > >>>> This option will indicate, when gateway sender is started, should = we > > >>>> discard/clean existing queue, or should we use existing queue. > > >>>> By default it will be to discard/clean existing queue. > > >>>> > > >>>> Best Regards, > > >>>> Mario > > >>>> ________________________________ > > >>>> =C5=A0alje: Mario Ivanac > > >>>> Poslano: 7. studenog 2019. 9:01 > > >>>> Prima: Dan Smith ; dev@geode.apache.org < > > >>>> dev@geode.apache.org> > > >>>> Predmet: Odg: gateway sender queue > > >>>> > > >>>> Hi, > > >>>> > > >>>> thanks for answers. > > >>>> > > >>>> Some more details regarding 1st question. > > >>>> > > >>>> Is this behavior same (for serial and parallel gateway sender) in > case > > >>>> queue is persistent? > > >>>> Meaning, should queue (persistent) be purged if we restart gateway > > >>> sender? > > >>>> > > >>>> Thanks, > > >>>> Mario > > >>>> > > >>>> ________________________________ > > >>>> =C5=A0alje: Dan Smith > > >>>> Poslano: 5. studenog 2019. 18:52 > > >>>> Prima: dev@geode.apache.org > > >>>> Predmet: Re: gateway sender queue > > >>>> > > >>>> Some replies, inline: > > >>>> > > >>>> * During testing we have observed, different behavior in > parallel > > >> and > > >>>>> serial gateway senders. In case we manually stop, than start > gateway > > >>>>> senders, for parallel gateway senders, queue is purged, but for > > >> serial > > >>>>> gateway senders this is not the case. Is this normal behavior or > bug? > > >>>>> > > >>>> Hmm, I also think stop is supposed to clear the queue. I think if > you > > >> are > > >>>> seeing that it doesn't clear the queue, that might be a bug. > > >>>> > > >>>> > > >>>> > > >>>>> * What happens with the queues when whole cluster is stopped > and > > >>>> later > > >>>>> started (In our tests with persistent queues, the events are kept= )? > > >>>>> > > >>>> Persistent queues will keep all of the events when you restart. > > >>>> > > >>>> > > >>>>> * Could we add extra option in gfsh command "start gateway > > >> sender" > > >>>>> that allows to control queues reset (for instance --cleanQueues)? > > >>>>> > > >>>> If stop does clear the queue, would this be needed? It might still > be > > >>>> reasonable - I've heard folks request a way to clear running queue= s > as > > >>>> well. > > >>>> > > >>>> -Dan > > >>>> > > > --000000000000e361ba059757f3e5--