[tarantool-patches] Re: [PATCH v2 7/7] relay: join new replicas off read view

[Vladimir Davydov]

On Thu, Aug 22, 2019 at 01:08:07AM +0300, Konstantin Osipov wrote:
> * Vladimir Davydov <vdavydov.dev at gmail.com> [19/08/20 17:08]:
> > On Tue, Aug 20, 2019 at 04:50:07PM +0300, Konstantin Osipov wrote:
> > > * Vladimir Davydov <vdavydov.dev at gmail.com> [19/08/20 15:10]:
> > > > Well, yeah, kinda. OTOH they do relay data to a replica that's why I
> > > > named them relay_something :-/ Also, those functions live in relay.cc,
> > > > which is consistent with the relay_ prefix.
> > > 
> > > engine_send? I'll think about it.
> > 
> > But the code is engine-agnostic now - it just opens read-view iterators
> > and sends whatever they return to a replica :-/
> 
> OK. Let's move it out of relay then. It's OK to put it in a
> special file or move to engine.cc. It's OK that it's
> engine-agnostic- engine.cc can have code common to all engines.

Okay, will do.

> 
> relay prefix is also confusing since in replication "relaying" is
> used to refer to re-sending some existing files or logs.
> 
> The only issue about this patch is that since, unlike a snapshot
> iterator, the code runs in tx thread, it may require some
> throttling. If the network is fast enough it the send loop may run
> at very high speeds. It could even hog 100% of CPU time and nearly
> never yield CPU to other transactions.

Good point.

> 
> I see two options here: move it to a separate thread (memtx
> iterators allow it, so it would be preferred), or throttle.

Unfortunately, I don't think we can move this code out of the tx thread,
because vinyl iterator must be run from tx (well, we could iterate over
run files in a thread, but not over the memory level; and we don't want
to suspend dumps/compaction until we're done joining a replica). So I
guess I will simply call fiber_sleep() periodically, similarly to how we
handle index build.