Tarantool development patches archive
 help / color / mirror / Atom feed
From: Konstantin Osipov <kostja@tarantool.org>
To: tarantool-patches@freelists.org
Cc: Georgy Kirichenko <georgy@tarantool.org>
Subject: [tarantool-patches] Re: [PATCH 2/2] On ctl event trigger
Date: Thu, 30 Aug 2018 17:45:43 +0300	[thread overview]
Message-ID: <20180830144543.GB3891@chai> (raw)
In-Reply-To: <20180830132128.gn32tdsunxl5wzbq@esperanza>

* Vladimir Davydov <vdavydov.dev@gmail.com> [18/08/30 16:25]:
> Another thought. I think that mixing space, applier, and global events
> in the same trigger isn't a good idea. I'd prefer box.ctl.on_event (or
> whatever it's going to be called) to be called only on global events,
> such as recovery completion or shutdown. Probably, it shouldn't be
> passed any context apart from the event type, because I can't think why
> it would ever need it (if it needs anything it can always get it from
> box.info).

What you're saying is that you should be able to subscribe to
only certain events. If you want to say, set a hook on shutdown
event, this hook shouldn't be handling other events. 
am I getting this right?

> 
> For applier events, I'd prefer to have a separate trigger, which would
> only be called whenever an applier state changes. It should be passed
> applier id in the arguments - everything else it can retrieve from
> box.info.

I disagree with voiding the trigger context. This creates a state
dependency between the trigger and the rest of the world - i.e.
when the trigger is really invoked the environment may change. I
think it's convenient to capture key event properties in a context
and pass it into the event. 

Put it differently, I don' tthink events are any different than
tarantool triggers. The only difference perhaps is that with ctl
api we provide a handy way to *subscribe* to any event from a
single place - i.e. it's like a single entry point to all events
we have, a message bus so to speak.

> Space events look rather superfluous to me, because we already can track
> creation of system objects with box space.on_replace. True, we can't
> install it before recovery is complete, but we could introduce a global
> event called on completion of recovery of all system spaces instead.
> We could use it to install before_replace trigger for conflict
> resolution.

Seems reasonable, I agree.
 
> Anyway, this topic cries for a discussion/brainstorming IMO.

-- 
Konstantin Osipov, Moscow, Russia, +7 903 626 22 32
http://tarantool.io - www.twitter.com/kostja_osipov

  reply	other threads:[~2018-08-30 14:45 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-28 16:19 [tarantool-patches] [PATCH 0/2] Box control " Georgy Kirichenko
2018-08-28 16:19 ` [tarantool-patches] [PATCH 1/2] Update lua space cache just after creation Georgy Kirichenko
2018-08-30 12:06   ` Vladimir Davydov
2018-08-31  4:57     ` [tarantool-patches] " Georgy Kirichenko
2018-08-30 12:31   ` Konstantin Osipov
2018-08-31  4:53     ` Georgy Kirichenko
2018-08-28 16:19 ` [tarantool-patches] [PATCH 2/2] On ctl event trigger Georgy Kirichenko
2018-08-30 12:07   ` Vladimir Davydov
2018-08-30 12:10   ` Vladimir Davydov
2018-08-30 12:38   ` Vladimir Davydov
2018-08-30 13:04     ` Georgy Kirichenko
2018-08-30 13:21     ` Vladimir Davydov
2018-08-30 14:45       ` Konstantin Osipov [this message]
2018-08-30 14:40     ` [tarantool-patches] " Konstantin Osipov
2018-08-30 12:50   ` Konstantin Osipov

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=20180830144543.GB3891@chai \
    --to=kostja@tarantool.org \
    --cc=georgy@tarantool.org \
    --cc=tarantool-patches@freelists.org \
    --subject='[tarantool-patches] Re: [PATCH 2/2] On ctl event trigger' \
    /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