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
next prev parent 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