[tarantool-patches] Re: [PATCH 1/1] rfc: describe proxy

[Konstantin Osipov <kostja@tarantool.org>]

* Vladislav Shpilevoy <v.shpilevoy@tarantool.org> [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(<new master UUID>)

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;<br>

> +**Advantages:** very simple to implement. It is not a
> performance critical place, so mutex looks ok;<br>


> +**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;<br>

> +**Advantages:** no locks;<br>
> +**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;<br>

> +**Advantages:** no mutexes;<br>
> +**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;<br>

> +**Advantages:** no locks, easy;<br>
> +**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).<br>

> +**Advantages:** in theory, it could speed up the requests
> processing;<br>
> +**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;<br>

> +**Advantages:** simple, lock-free, new clients can not see
> expired data, proxy auth is stateless<br>
> +**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