Github user ahgittin commented on the issue:
https://github.com/apache/brooklyn-server/pull/565
@aledsage Sorry for the confusion. Thanks for long exposition. I thought
almost everyone hated the "wait" as part of "immediate", from discussions ages
ago somewhere. Waiting 200ms is smelly. And it hurts us writing deterministic
tests, and causes nasty delays when we validate (e.g. add 1000 unresolved
dependents as config keys and startup will be 3m+ while it waits for them to
"validate"!). Surprised that you do like it as usually it's me being loosy
goosy!
Immediate eval was not guaranteed before in any circumstances (anything can
take >200ms or whatever the threshhold was) so it is a strict improvement in
contract that now we do guarantee immediate eval for non-blocking code.
Yes some blocking tasks which previously succeeded in practice for
immediate eval now will not. However I think there are very few of these.
None of the old tests failed which gave confidence for this change (much of
which was done in #565 hence the brevity here).
I'm investigating your new test but to me sleeping (for any length) while
someone is waiting on your "immediate" value shouldn't be acceptable. If the
caller does want short-timeout behaviour that codepath is still available (and
used by immediate in a few cases, e.g. shared tasks as config value). (It
might be appropriate when the REST API is doing get-all-config for instance,
possibly as an API argument?)
As for `external(...)` is it really the case that such refs now *all* fail?
Or is it just those that require blocking I/O? Either way I think we rewrite
any bits that are important (local file access? though hardly necessary) and
accept that immediate isn't supported for others. (Haven't looked at this yet
-- wanted to reply conceptually before looking at code.)
I think there are some places that a suprising `InterruptedException` might
be thrown (ISTR latches check this even when not blocking) but we can live with
this.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
