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