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 31197452566 for ; Thu, 14 Nov 2019 18:26:59 +0300 (MSK) Received: by mail-lj1-f194.google.com with SMTP id r7so7143601ljg.2 for ; Thu, 14 Nov 2019 07:26:59 -0800 (PST) Date: Thu, 14 Nov 2019 18:26:56 +0300 From: Konstantin Osipov Message-ID: <20191114152656.GA12369@atlas> References: <20191114125705.26760-1-maria.khaydich@tarantool.org> <20191114134422.GA8372@atlas> <13232148.CanJsBF7IP@home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <13232148.CanJsBF7IP@home.lan> Subject: Re: [Tarantool-patches] [PATCH] Trigger on vclock change List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Georgy Kirichenko Cc: tarantool-patches@dev.tarantool.org * Georgy Kirichenko [19/11/14 17:11]: > On Thursday, November 14, 2019 4:44:22 PM MSK Konstantin Osipov wrote: > > * Maria [19/11/14 15:59]: > > > This patch implements replication.on_vclock > > > trigger that can be useful for programming > > > shard-systems with redundancy. > > > > 3808 is about being able to wait for an lsn. > > > > Using a trigger for *waiting* is called busy waiting, and is a cpu > > hog, especially at a performance critical space like update of > > replica vclock, which can happen a hundred times a second. > > > > Why not implement a way to wait for an lsn instead? > Please explain your proposal in a more detailed way. > Do you wish to implement a hard-coded `handler` and each time when a replica > vclock is updated this handler will compare the updated vclock against members > of set of replica_id:lsn pairs organized in a list, tree or something else? > And if a compare matches to true then a corresponding handler will be called? Yes, quite simply wait_lsn() could add the server_id, lsn that is being waited for to a sorted list, and whenever we update replicaset vclock for this lsn we also look at top of the list, if it is not empty, and if the current lsn is greater than the top, we could pop the value from the list and send a notification to the waiter. I also think it it's a pair of server_id, lsn, rather than entire vclock - usually you know what you're waiting for, and it's only one component of vclock, not all of them. Going forward I think one is better off using synchronous replication, not wait-lsn, since wait_lsn doesn't roll back the transaction on failure. Why did you decide to do this ticket at all? > Anyway, we will need to have such trigger in order to make applier able to > report local replica wal and commited vclock in scope of synchronous > replication issue. This has to happen in WAL thread, not in main thread, and has to watch relay-from-memory vclock, not async-replication vclock. And it also needs to roll back the transaction locally on failure, i.e. write some sort of undo records to the WAL. -- Konstantin Osipov, Moscow, Russia