Tarantool development patches archive
 help / color / mirror / Atom feed
From: Vladislav Shpilevoy via Tarantool-patches <tarantool-patches@dev.tarantool.org>
To: Serge Petrenko <sergepetrenko@tarantool.org>,
	Cyrill Gorcunov <gorcunov@gmail.com>
Cc: tml <tarantool-patches@dev.tarantool.org>
Subject: Re: [Tarantool-patches] [PATCH v23 3/3] test: add gh-6036-qsync-order test
Date: Fri, 22 Oct 2021 00:06:07 +0200	[thread overview]
Message-ID: <b5b13af5-a8e2-06dd-7fb8-7d88b242a934@tarantool.org> (raw)
In-Reply-To: <f7da70a1-a3a5-230a-ae0b-8f5cd024be5a@tarantool.org>

>>> Actually you do need to count writes here.
>>> The wait_cond for ERRINJ_WAL_WRITE_COUNT == write_cnt + 3
>>> is needed to make sure you receive (and thus try to process)
>>> insert {3} **before** the replica is re-enabled.
>>>
>>> Otherwise we can't be sure that the test is correct. You may simply
>>> perform a select before insert{3} has reached the replica.
>> You know, I spent a few hours trying to pass the test waiting for
>> ERRINJ_WAL_WRITE_COUNT == write_cnt + 3 and finally realized that
>> it seems that is what happens: the replica1 is not longer a leader
>> and when this record reach our replica3 node we NOPify it then
>> we run
>>
>> apply_row
>>    if (request.type == IPROTO_NOP)
>>      return process_nop()
>>
>> thus this record even not reaching the journal at all and that is
>> why waiting for write_cnt + 3 lasts forever. If only I didn't miss
>> something obvious.
> 
> Unfortunately, this is not the case. A NOP entry still reaches WAL.
> That's why we need NOP entries: they reside in WAL but do nothing.
> That's for vclock bump sake. Otherwise we could skip such entries
> completely, without nopifying them.
> 
> So, even if the entry is nopified, it would enter WAL sooner or later.
> 
> I just realised what the problem is: the entry is waiting on a limbo latch
> inside the NOPify procedure. That's why it never reaches the journal
> (until we re-enable replica3, at least).
> 
> I don't know how to wait for this entry's arrival then.
> The current test version looks OK to me.
> 
> Vlad, do you have any ideas here?

I think it might worth adding an errinj for the number of blocked
fibers waiting on the limbo latch. Could even expose that to box.info.qsync,
seems like useful info. Would help to measure contention.

  reply	other threads:[~2021-10-21 22:06 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-14 21:56 [Tarantool-patches] [PATCH v23 0/3] qsync: implement packet filtering (part 1) Cyrill Gorcunov via Tarantool-patches
2021-10-14 21:56 ` [Tarantool-patches] [PATCH v23 1/3] latch: add latch_is_locked helper Cyrill Gorcunov via Tarantool-patches
2021-10-14 21:56 ` [Tarantool-patches] [PATCH v23 2/3] qsync: order access to the limbo terms Cyrill Gorcunov via Tarantool-patches
2021-10-21 22:06   ` Vladislav Shpilevoy via Tarantool-patches
2021-10-14 21:56 ` [Tarantool-patches] [PATCH v23 3/3] test: add gh-6036-qsync-order test Cyrill Gorcunov via Tarantool-patches
2021-10-19 15:09   ` Serge Petrenko via Tarantool-patches
2021-10-19 22:26     ` Cyrill Gorcunov via Tarantool-patches
2021-10-20  6:35       ` Serge Petrenko via Tarantool-patches
2021-10-21 22:06         ` Vladislav Shpilevoy via Tarantool-patches [this message]
2021-10-22  6:36           ` Serge Petrenko via Tarantool-patches
2021-10-21 22:06   ` Vladislav Shpilevoy via Tarantool-patches
2021-10-22 22:03     ` Cyrill Gorcunov via Tarantool-patches
2021-10-24 15:39       ` Vladislav Shpilevoy via Tarantool-patches
2021-10-24 16:01         ` Cyrill Gorcunov via Tarantool-patches

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b5b13af5-a8e2-06dd-7fb8-7d88b242a934@tarantool.org \
    --to=tarantool-patches@dev.tarantool.org \
    --cc=gorcunov@gmail.com \
    --cc=sergepetrenko@tarantool.org \
    --cc=v.shpilevoy@tarantool.org \
    --subject='Re: [Tarantool-patches] [PATCH v23 3/3] test: add gh-6036-qsync-order test' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox