From dev-return-31901-archive-asf-public=cust-asf.ponee.io@geode.apache.org Wed Sep 11 15:46:09 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 1CE1D18063F for ; Wed, 11 Sep 2019 17:46:09 +0200 (CEST) Received: (qmail 91390 invoked by uid 500); 11 Sep 2019 15:46:08 -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 91379 invoked by uid 99); 11 Sep 2019 15:46:08 -0000 Received: from Unknown (HELO mailrelay1-lw-us.apache.org) (10.10.3.159) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 11 Sep 2019 15:46:08 +0000 Received: from mail-io1-f70.google.com (mail-io1-f70.google.com [209.85.166.70]) by mailrelay1-lw-us.apache.org (ASF Mail Server at mailrelay1-lw-us.apache.org) with ESMTPSA id 2A6D75A5D for ; Wed, 11 Sep 2019 15:46:08 +0000 (UTC) Received: by mail-io1-f70.google.com with SMTP id j23so28256659iog.16 for ; Wed, 11 Sep 2019 08:46:08 -0700 (PDT) X-Gm-Message-State: APjAAAXfS2pGcXpUpRv9NPsyJefvi5+GPguT3skGecNFJiHgG/ioawid b6gT3iLULsZhIEVxs891XJTQUMIoa0SyBuSKm9/B8lwvypPJXFmmQOn0QDp3m7Cpme7TX18agU7 XUJqsiQHEhNnHyjiluq7b5mj7E5xmOsvbSdwElVYVPDPiYLmh2Bn+28U= X-Received: by 2002:a05:6638:4b:: with SMTP id a11mr38342045jap.0.1568216766935; Wed, 11 Sep 2019 08:46:06 -0700 (PDT) X-Google-Smtp-Source: APXvYqynrzUcQb8EYQdHCoKZcsaboLwHeOU2TBCKCluKhMJaNIXr5irtrxh2OmWzxIYqTpAeP/BrmX8ARg46sZxCtf0= X-Received: by 2002:a05:6638:4b:: with SMTP id a11mr38342033jap.0.1568216766826; Wed, 11 Sep 2019 08:46:06 -0700 (PDT) MIME-Version: 1.0 References: <5CB3AFCF-1841-48F4-8347-C2DDA9B1D462@pivotal.io> <05d311d8-5348-dffb-aa55-966f0a9e4024@pivotal.io> In-Reply-To: <05d311d8-5348-dffb-aa55-966f0a9e4024@pivotal.io> From: Jens Deppe Date: Wed, 11 Sep 2019 08:45:55 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [Proposal] Make gfsh "stop server" command synchronous To: dev@geode.apache.org Content-Type: multipart/alternative; boundary="000000000000516599059248eb56" --000000000000516599059248eb56 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable To circle back to the original test failure that prompted this discussion - the failing test was getting intermittent bind exceptions on subsequent server restarts. I believe it's quite likely that a process' ports will remain unavailable even after it is gone (I'm not sure if we create listening sockets with SO_REUSEADDR). So, as to John's comment that gfsh is already synchronous, I don't think that adding extra functionality to gfsh, to ultimately just wait longer before exiting, is really solving the problem. I'd suggest you adjust the tests to always start servers with `--server-port=3D0` so that there are no port conflicts and let the OS handle it. --Jens On Wed, Sep 11, 2019 at 8:17 AM Bruce Schuchardt wrote: > Blocking or non-blocking, I don't have a strong opinion. What I'd > really like to have gfsh ensure, though, is that no-one is able to start > a new instance of a server while the old process is still around. Maybe > the PID file is the way to do that. > > On 9/10/19 3:08 PM, Mark Hanson wrote: > > Hello All, > > > > I would like to propose that we make the gfsh =E2=80=9Cstop server=E2= =80=9D command > synchronous. It is causing some issues with some tests as the rest of the > calls are blocking. Stop on the other hand immediately returns by > comparison. > > This causes issues as shown in GEODE-7017 specifically. > > > > GEODE:7017 CI failure: > org.apache.geode.launchers.ServerStartupValueRecoveryNotificationTest > > startupReportsOnlineOnlyAfterRedundancyRestored > > https://issues.apache.org/jira/browse/GEODE-7017 < > https://issues.apache.org/jira/browse/GEODE-7017> > > > > > > What do people think? > > > > Thanks, > > Mark > --000000000000516599059248eb56--