From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id BF0702D690 for ; Thu, 5 Apr 2018 16:23:56 -0400 (EDT) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ibTjcFcACd-k for ; Thu, 5 Apr 2018 16:23:56 -0400 (EDT) Received: from smtp61.i.mail.ru (smtp61.i.mail.ru [217.69.128.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTPS id 7D1322D68F for ; Thu, 5 Apr 2018 16:23:56 -0400 (EDT) Date: Thu, 5 Apr 2018 23:23:53 +0300 From: Konstantin Osipov Subject: [tarantool-patches] Re: [PATCH 1/1] rfc: describe proxy Message-ID: <20180405202353.GD3953@atlas> References: <20180327110504.GA26560@atlas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: tarantool-patches-bounce@freelists.org Errors-to: tarantool-patches-bounce@freelists.org Reply-To: tarantool-patches@freelists.org List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: tarantool-patches List-subscribe: List-owner: List-post: List-archive: To: Vladislav Shpilevoy Cc: tarantool-patches@freelists.org * Vladislav Shpilevoy [18/04/05 17:28]: > +API, first variant of proxy up: > +```Lua > +-- At first, turn on proxy. > +netbox = require('net.box') > +proxy = netbox.listen(...) > +-- Now the proxy accepts requests, but does not forward > +-- them. > +box.cfg({ > + -- When a proxy is up, the box.cfg > + -- can do not care about listen. > + listen = nil, It's OK for listen to work as before. > + replication = { cluster_members }, > + -- Other options ... > +}) > +``` > +API, second variant of proxy up: > +```Lua > +-- At first, run box.cfg. > +box.cfg({ > + listen = ..., > + replication = { cluster_members }, > +}) > +-- Now Tarantool is up, but does not forward requests. > +netbox = require('net.box') > +-- Start a proxy with no specified URI - in such a case > +-- the proxy takes a listening socket from a server and > +-- starts forwarding. > +proxy = netbox.listen() Please drop this one. > +``` > + > +After the proxy is started it can be failovered both manualy > +```Lua > +proxy.failover() I don't think we need manual or automatic failover. We should integrate box.ctl.promote() and proxy failover instead. > +The next point at issue is how IProto thread would read auth > info from TX thread, when a new client is connected. There are > several alternatives: > +* Protect write access to user hash with a mutex. TX thread > locks the mutex when writing, and does not lock it for reading, > since TX is an exclusive writer. IProto thread meanwhile locks > the mutex whenever it needs to read `hash2` to establish an > outgoing connection;
> +**Advantages:** very simple to implement. It is not a > performance critical place, so mutex looks ok;
> +**Shortcomings:** it is not a common practice in Tarantool to > use mutexes. It looks like a crutch; > +* Maintain a copy of the user hash in iproto thread, and > propagate changes to the copy via cbus, in new on_replace > triggers added to the system spaces;
> +**Advantages:** no locks;
> +**Shortcomings:** it is possible, then a client connects, when > a hash copy in IProto thread is expired. And it is relatively > hard to implement; > +* Use a single copy of the users hash in TX thread, but protect > access to this copy by `fiber.cond` object local to IProto > thread. Lock/unlock the cond for IProto thread by sending a > special message to it via cbus;
> +**Advantages:** no mutexes;
> +**Shortcomings:** the hash can expire in the same scenario, as > in the previous variant. Hard to implement; > +* We use persistent schema versioning and update the state of > IProto thread on demand, whenever it notices that schema version > has changed;
> +**Advantages:** no locks, easy;
> +**Shortcomings:** at first, it does not solve the problem - how > to get the changes from TX thread? At second, schema is not > updated, when a users hash is changed. And it is strange to > update version for it. > +* We kill iproto thread altogether and forget about the problem > of IProto-TX synch forever (it is not a big patch and it may > well improve our performance results).
> +**Advantages:** in theory, it could speed up the requests > processing;
> +**Shortcomings:** it slows down all slaves, since proxy on a > slave works entirely in IProto thead. If a proxy is not in a > thread, then on a slave it will occupy CPU just to encode/decode > requests, send/receive data, do `SYNC`s translation. When a > routing rules will be introduced, it will occupy even more CPU; > +* On each new client connection get needed data from a user > hash using special cbus message;
> +**Advantages:** simple, lock-free, new clients can not see > expired data, proxy auth is stateless
> +**Shortcomings:** ? What happens if the data changes after the client has connected? then you get all the shortcomings of the rejected proposals. In a nutshell, this proposal is not different from tracking schema_version and re-fetching the schema when it changes, but more pessimistic in nature. > + > +The last method seems to be the most useful. :) -- Konstantin Osipov, Moscow, Russia, +7 903 626 22 32 http://tarantool.io - www.twitter.com/kostja_osipov