Reactive when_file_changed decorator question

[Cory Johns]

Merlijn,

You are correct, the order of handlers is undetermined, so it is entirely
possible for the execution order to be: handler1, handler2, handler3,
handler2.

The predicates, including the @when_changed test, will be checked again
after each round of dispatch, so handler2 should definitely be called again
after handler3.  If you're not careful, this can lead to inefficiencies in
your charm, which has been discussed previously here, and on issues on the
charms.reactive repo (
https://github.com/juju-solutions/charms.reactive/issues).  Stuart Bishop,
in particular, has raised several very good concerns about ensuring
intelligent handling of expensive operations such as apt-get calls or
service restarts, when dealing with constructs such as these.

While checking the code to verify my answers here, I realized that the
logic for managing re-invocation of state handlers (so that, e.g.,
@when('A') doesn't just keep matching and executing over and over in a
given hook invocation, while still allowing it to run again if the A state
changes) will override non-state predicates such as @when_file_changed.
That means that if you combine @when and @when_file_changed, handler2 might
*not* get reinvoked the second time (at least not until the next hook).  I
opened https://github.com/juju-solutions/charms.reactive/issues/49 to track
this.

There are also a couple of other open issues regarding @when_file_changed
that you should be aware of:
https://github.com/juju-solutions/charms.reactive/issues/25
https://github.com/juju-solutions/charms.reactive/issues/44

I'm still not sure what the right solution for these issues is, so input on
those is welcome.

On Thu, Jan 28, 2016 at 9:55 AM, Merlijn Sebrechts <
merlijn.sebrechts at gmail.com> wrote:

> Hi Cory
>
>
> I have a question about the reactive handlers. How exactly do
> when_file_changed handlers get dispatched? Consider the following:
>
>
> @when('init')
> def handler1():
>     change_file('file1')
>     set_state('A')
>
> @when_changed('file1')
> def handler2():
>     restart_service()
>
> @when('A')
> def handler3():
>     change_file('file1')
>
>
> The order in which handlers are dispatched is random afaik, so there is
> the possibility that handler2 is executed before handler3. This would mean
> file1 is changed again after executing handler2. Will handler2 be executed
> again?
>
>
>
> Kind regards
> Merlijn Sebrechts
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20160128/e413f8c2/attachment.html>