brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <>
Subject [jira] [Commented] (BROOKLYN-356) The sensor Transformer enricher fails to resolve its targetValue indeterministically.
Date Thu, 20 Oct 2016 09:47:58 GMT


ASF GitHub Bot commented on BROOKLYN-356:

GitHub user aledsage opened a pull request:

    BROOKLYN-356: fix race in transformer by adding getImmediately


You can merge this pull request into a Git repository by running:

    $ git pull BROOKLYN-356-getImmediately

Alternatively you can review and apply these changes as the patch at:

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #390
commit 77b06dd664c03371746bf9c9c9cf808ead8e125d
Author: Aled Sage <>
Date:   2016-10-13T21:46:57Z

    Subscription callbacks: task has contextEntity tag

commit 9b896cbc5abdb03d886a4c98d8323d63fa7bc26f
Author: Aled Sage <>
Date:   2016-10-18T18:08:18Z

    BROOKLYN-356: threading for DSL task
    Adds ImmediateSupplier, so can fetch Maybe<?> of DSL value immediately,
    in current thread (rather than invoking in task with a timeout).

commit 516128f56197763d5f15850336d2af85ce8197b4
Author: Aled Sage <>
Date:   2016-10-19T14:46:53Z

    Reflections utils: improve use of generics


> The sensor Transformer enricher fails to resolve its targetValue indeterministically.
> -------------------------------------------------------------------------------------
>                 Key: BROOKLYN-356
>                 URL:
>             Project: Brooklyn
>          Issue Type: Bug
>            Reporter: Svetoslav Neykov
> The sensor {{Transformer}} enricher fails to resolve its {{targetValue}} indeterministically,
especially so on loaded systems. This is especially problematic if sourceSensor/triggerSensors
change infrequently or do not change ever (when using default values).
> Bueprints using the {{Transformer}} behave perfectly fine during development and on test
setups, but will fail on production machines (i.e. under load).
> The code [doing the value resolving|]
tries to do so in a non-blocking fashion by spinning a thread to try to resolve and cancelling
it after a short while without guarantees it ever got scheduled to run. It's more likely to
fail when nesting DSLs, for example nesting several levels of {{$brooklyn:formatString}} and
ending with a {{$brooklyn:attributeWhenRready}}. It's a common pattern in moderately complex
blueprints. It needs to schedule a thread for each nesting level thus maximizing the chance
that the value will not be resolved in the allotted time even if resolvabe. This is especially
bad for sensors which don't get updated, for example {{PortAttributeSensorAndConfigKey} set
only when initializing the entity or any config values which are always resolvable.

This message was sent by Atlassian JIRA

View raw message