From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <vdavydov.dev@gmail.com>
Date: Thu, 9 Aug 2018 15:20:11 +0300
From: Vladimir Davydov <vdavydov.dev@gmail.com>
Subject: Re: [tarantool-patches] Re: [PATCH v2] replication: do not ignore
 replication_connect_quorum.
Message-ID: <20180809122011.azcmyh5qnuipm3uh@esperanza>
References: <20180807124413.14947-1-sergepetrenko@tarantool.org>
 <20180807172847.z7h7476jedxktwno@esperanza>
 <34F1BCA9-2C61-4C3A-939D-F90E745B349D@tarantool.org>
 <20180809091101.hzsxrym3zgndgmgz@esperanza>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20180809091101.hzsxrym3zgndgmgz@esperanza>
To: Sergey Petrenko <sergepetrenko@tarantool.org>
Cc: Georgy Kirichenko <georgy@tarantool.org>, tarantool-patches@freelists.org
List-ID: <tarantool-patches.dev.tarantool.org>

On Thu, Aug 09, 2018 at 12:11:01PM +0300, Vladimir Davydov wrote:
> > >> diff --git a/test/replication-py/master.lua b/test/replication-py/master.lua
> > >> index 0f9f7a6f0..51283efdf 100644
> > >> --- a/test/replication-py/master.lua
> > >> +++ b/test/replication-py/master.lua
> > >> @@ -3,6 +3,8 @@ os = require('os')
> > >> box.cfg({
> > >>     listen              = os.getenv("LISTEN"),
> > >>     memtx_memory        = 107374182,
> > >> +    replication_connect_timeout = 1.0,
> > >> +    replication_timeout = 0.3
> > > 
> > > Why do you need to adjust the timeouts?
> > 
> > The timeouts set in all cfg files in all the tests had no effect, just like the
> > replication_connect_quorum option, cos both of the options were ignored
> > During bootstrap. We wanted every replica to connect, and the timeout was
> > Set to TIMEOUT_INFINITY. Now when we actually start passing
> > replication_connect_timeout, all these timeouts become too small.
> 
> Some tests now take too long because of this. E.g. replication/quorum
> runs for 15 seconds for memtx+vinyl without this patch, which is already
> long enough, but with this patch it takes more than 30 seconds. We need
> to do something about that.

May be, we could pass replication_connect_timeout to these scripts
in arguments and use different timeouts for bootstrap and subsequent
restarts?