Tarantool development patches archive
 help / color / mirror / Atom feed
From: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
To: sergepetrenko <sergepetrenko@tarantool.org>, georgy@tarantool.org
Cc: tarantool-patches@dev.tarantool.org
Subject: Re: [Tarantool-patches] [PATCH 3/5] applier: split join processing into two stages
Date: Sun, 22 Dec 2019 18:59:18 +0100	[thread overview]
Message-ID: <885e77f9-b9dd-698e-246e-c9c9cd44b6ab@tarantool.org> (raw)
In-Reply-To: <5a75434034d9e6a269b31b2f0a050c19da860646.1576443171.git.sergepetrenko@tarantool.org>

Thanks for the patch!

See 2 comments below.

On 15/12/2019 21:58, sergepetrenko wrote:
> From: Serge Petrenko <sergepetrenko@tarantool.org>
> 
> We already have 'initial join' and 'final join' stages in applier logic.
> The first actually means fetching master's snapshot, and the second one
> -- receiving the rows which should contain replica's registration in
> _cluster.
> These stages will be used separately once anonymous replica is
> implemented, so split them as a preparation.
> 
> Prerequisite #3186
> ---
>  src/box/applier.cc | 61 ++++++++++++++++++++++++++++++++++++----------
>  1 file changed, 48 insertions(+), 13 deletions(-)
> 
> diff --git a/src/box/applier.cc b/src/box/applier.cc
> index 42374f886..357369025 100644
> --- a/src/box/applier.cc
> +++ b/src/box/applier.cc
> @@ -388,18 +388,12 @@ done:
>  	applier_set_state(applier, APPLIER_READY);
>  }
>  
> -/**
> - * Execute and process JOIN request (bootstrap the instance).
> - */
> -static void
> -applier_join(struct applier *applier)
> +static uint64_t
> +applier_do_fetch_snapshot(struct applier *applier)
>  {
> -	/* Send JOIN request */
>  	struct ev_io *coio = &applier->io;
>  	struct ibuf *ibuf = &applier->ibuf;
>  	struct xrow_header row;
> -	xrow_encode_join_xc(&row, &INSTANCE_UUID);
> -	coio_write_xrow(coio, &row);
>  
>  	/**
>  	 * Tarantool < 1.7.0: if JOIN is successful, there is no "OK"

1. applier_do_fetch_snapshot() still uses JOIN in some comments
and in apply_initial_join_row() function name. The function can
be renamed right here. The comments should be fixed when you add
REQUEST_SNAPSHOT.

Also I propose you to rename it to just applier_fetch_snapshot().
And the applier_fetch_snapshot() which you add later rename to
applier_request_and_fetch_snapshot(). But it is arguable. Lets
discuss if you disagree. I don't have a strong opinion here.

Another option - rename it to applier_wait_snapshot(). It will be
consistent with what I propose below.

> @@ -456,9 +448,16 @@ applier_join(struct applier *applier)
>  				  (uint32_t) row.type);
>  		}
>  	}
> -	say_info("initial data received");
>  
> -	applier_set_state(applier, APPLIER_FINAL_JOIN);
> +	return row_count;
> +}
> +
> +static uint64_t
> +applier_do_register(struct applier *applier, uint64_t row_count)

2. This looks rather like 'wait_register' because the only thing it
does is waiting for register response.

> +{
> +	struct ev_io *coio = &applier->io;
> +	struct ibuf *ibuf = &applier->ibuf;
> +	struct xrow_header row;
>  
>  	/*
>  	 * Tarantool < 1.7.0: there is no "final join" stage.

  reply	other threads:[~2019-12-22 17:59 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-15 20:56 [Tarantool-patches] [PATCH 0/5] introduce anonymous replicas sergepetrenko
2019-12-15 20:58 ` [Tarantool-patches] [PATCH 1/5] box: update comment describing join protocol sergepetrenko
2019-12-22 17:58   ` Vladislav Shpilevoy
2019-12-23 21:12     ` Sergey Petrenko
2019-12-15 20:58 ` [Tarantool-patches] [PATCH 2/5] replication: do not decode replicaset uuid when processing a subscribe sergepetrenko
2019-12-15 20:58 ` [Tarantool-patches] [PATCH 3/5] applier: split join processing into two stages sergepetrenko
2019-12-22 17:59   ` Vladislav Shpilevoy [this message]
2019-12-23 22:10     ` Sergey Petrenko
2019-12-24 15:50       ` Vladislav Shpilevoy
2019-12-15 20:58 ` [Tarantool-patches] [PATCH 4/5] vclock: ignore 0th component in comparisons sergepetrenko
2019-12-22 17:59   ` Vladislav Shpilevoy
2019-12-23 21:26     ` Sergey Petrenko
2019-12-23 22:58       ` Sergey Petrenko
2019-12-26  4:43   ` Konstantin Osipov
2019-12-26  5:02     ` Konstantin Osipov
2019-12-27 12:56       ` Sergey Petrenko
2019-12-27 13:31         ` Konstantin Osipov
2019-12-27 13:48           ` Sergey Petrenko
2019-12-27 14:40             ` Konstantin Osipov
2019-12-15 20:58 ` [Tarantool-patches] [PATCH 5/5] replication: introduce anonymous replica sergepetrenko
2019-12-16 13:28   ` Serge Petrenko
2019-12-20 12:06     ` Serge Petrenko
2019-12-22 17:58   ` Vladislav Shpilevoy
2019-12-25 12:40     ` Sergey Petrenko
2019-12-25 18:23       ` Vladislav Shpilevoy
2019-12-26 16:08         ` Sergey Petrenko
2019-12-15 21:00 ` [Tarantool-patches] [PATCH 0/5] introduce anonymous replicas Sergey Petrenko
2019-12-18  7:49 ` Georgy Kirichenko
2019-12-20 12:07   ` Serge Petrenko
2019-12-20 12:17     ` Serge Petrenko
2019-12-22 17:59 ` Vladislav Shpilevoy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=885e77f9-b9dd-698e-246e-c9c9cd44b6ab@tarantool.org \
    --to=v.shpilevoy@tarantool.org \
    --cc=georgy@tarantool.org \
    --cc=sergepetrenko@tarantool.org \
    --cc=tarantool-patches@dev.tarantool.org \
    --subject='Re: [Tarantool-patches] [PATCH 3/5] applier: split join processing into two stages' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox