From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-f194.google.com (mail-lj1-f194.google.com [209.85.208.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id 22760469719 for ; Sat, 7 Mar 2020 00:57:58 +0300 (MSK) Received: by mail-lj1-f194.google.com with SMTP id r7so3775257ljp.10 for ; Fri, 06 Mar 2020 13:57:58 -0800 (PST) Date: Sat, 7 Mar 2020 00:57:55 +0300 From: Cyrill Gorcunov Message-ID: <20200306215755.GC27301@uranus> References: <20200305122943.7324-1-gorcunov@gmail.com> <20200305122943.7324-10-gorcunov@gmail.com> <20200306213743.GI8140@atlas> <20200306214145.GB27301@uranus> <20200306215103.GK8140@atlas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200306215103.GK8140@atlas> Subject: Re: [Tarantool-patches] [PATCH 09/10] box/journal: journal_entry_new -- drop setting up callbacks List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Konstantin Osipov , tml On Sat, Mar 07, 2020 at 12:51:03AM +0300, Konstantin Osipov wrote: > * Cyrill Gorcunov [20/03/07 00:44]: > > But vinyl test case fails > > > > 2020-03-07 00:35:51.116 [6494] main/136/applier/unix/:/home/cyrill/sda1 I> subscribed > > 2020-03-07 00:35:51.116 [6494] main/136/applier/unix/:/home/cyrill/sda1 I> remote vclock {1: 782} local vclock {1: 382} > > tarantool: /home/cyrill/sda1/tarantool/tarantool.git/src/box/vy_tx.c:803: void vy_tx_commit(struct vy_tx *, int64_t): Assertion `xm->lsn <= lsn' failed. > > [001] replication/gc.test.lua vinyl > > This has to do most likely with out-of-order invocation of the > wakeup callbacks. > > Are these sync callbacks or async callbacks? To be honest -- I don't know at the moment. This is replication test if I understand correctly and I presume these are async calls, but not sure yet. What is interesting is that vinyl internally use journal entries and calls cbus directly to write the data (again, if I understand correctly 'cause I know nothing about vinyl internals) and this might be the reason. > When a batch of transactions are submitted to wal, they got to be > scheduled to commit in the order of their lsn. > > the order gets broken here for some reason. Please find out why. Yes. Will continue the next week. And thanks a huge for all your comments. I'll try to address them in next series once I finish hunting this test issue. You know this series of patches is a bit ugly but once we have a working set of patches we will beautify them the way we like.