From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <v.shpilevoy@tarantool.org> Received: from smtp44.i.mail.ru (smtp44.i.mail.ru [94.100.177.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id C7BB24696C3 for <tarantool-patches@dev.tarantool.org>; Sat, 2 May 2020 23:09:20 +0300 (MSK) References: <cover.1588292014.git.v.shpilevoy@tarantool.org> <badc06d86e3f52b59453184d42f2f1e5d0537e47.1588292014.git.v.shpilevoy@tarantool.org> <40b31a98-794a-82f6-4332-37996194ac8b@tarantool.org> From: Vladislav Shpilevoy <v.shpilevoy@tarantool.org> Message-ID: <77fc8155-27d7-84c3-39ac-444bd773085a@tarantool.org> Date: Sat, 2 May 2020 22:09:17 +0200 MIME-Version: 1.0 In-Reply-To: <40b31a98-794a-82f6-4332-37996194ac8b@tarantool.org> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [Tarantool-patches] [PATCH vshard 3/7] test: disable router discovery for some tests List-Id: Tarantool development patches <tarantool-patches.dev.tarantool.org> List-Unsubscribe: <https://lists.tarantool.org/mailman/options/tarantool-patches>, <mailto:tarantool-patches-request@dev.tarantool.org?subject=unsubscribe> List-Archive: <https://lists.tarantool.org/pipermail/tarantool-patches/> List-Post: <mailto:tarantool-patches@dev.tarantool.org> List-Help: <mailto:tarantool-patches-request@dev.tarantool.org?subject=help> List-Subscribe: <https://lists.tarantool.org/mailman/listinfo/tarantool-patches>, <mailto:tarantool-patches-request@dev.tarantool.org?subject=subscribe> To: Oleg Babin <olegrok@tarantool.org>, tarantool-patches@dev.tarantool.org Thanks for the review! >> @@ -49,13 +51,13 @@ util.collect_timeouts(rs1) >> ok: 0 >> timeout: 0.5 >> - fail: 0 >> - ok: 1 >> + ok: 0 >> timeout: 0.5 >> ... >> util.collect_timeouts(rs2) >> --- >> - - fail: 0 >> - ok: 1 >> + ok: 0 >> timeout: 0.5 >> - fail: 0 >> ok: 0 >> @@ -74,7 +76,7 @@ util.collect_timeouts(rs1) >> ok: 0 >> timeout: 0.5 >> - fail: 0 >> - ok: 9 >> + ok: 8 >> timeout: 0.5 >> ... >> _ = rs1:callrw('echo') >> @@ -86,7 +88,7 @@ util.collect_timeouts(rs1) >> ok: 0 >> timeout: 0.5 >> - fail: 0 >> - ok: 1 >> + ok: 9 >> timeout: 0.5 >> ... > > Sorry for maybe quite stupid question, but why does it quite significantly increase? > ``` > net_sequential_ok - count of sequential success requests to the replica > ``` This is because the value is truncated to 1, when becomes >= 10. Since there is no discovery, this makes number of successful requests decremented. Before the patch value was 1. So 1 - 1 = 0, this brings the counter to its previous round, where it ended up being 9. After 10 the counter is truncated, because the only thing which matters - did it manage to make 10 successful requests in a row or not. If it did, the timeout is decreased. If it managed, then can start from 1 again.