[tarantool-patches] Re: [PATCH 2/2] On ctl event trigger

Konstantin Osipov kostja at tarantool.org
Thu Aug 30 17:45:43 MSK 2018


* Vladimir Davydov <vdavydov.dev at 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




More information about the Tarantool-patches mailing list