[jira] [Commented] (BROOKLYN-356) The sensor Transformer enricher fails to resolve its targetValue indeterministically.

["ASF GitHub Bot (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/BROOKLYN-356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15540374#comment-15540374 ] 

ASF GitHub Bot commented on BROOKLYN-356:
-----------------------------------------

GitHub user neykov opened a pull request:

    https://github.com/apache/brooklyn-server/pull/365

    [BROOKLYN-356] Transformer value resolver test

    * Adds thread startup jittering so we can lure out any concurrency bugs hiding in the code base. Testing `core` with this results in a handful of failures. Similar problems are very apparent on the windows builds where the machines have a single CPU and are frequently failing. I'd enable this by default for testing only if it wasn't slowing the tests to a craw.
    * Adds a test which shows the problem with the transformer resolver. It's failing under normal conditions infrequently, so use with the above enabled.

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

    $ git pull https://github.com/neykov/brooklyn-server transformer-resolver-test

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

    https://github.com/apache/brooklyn-server/pull/365.patch

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

    This closes #365
    
----
commit 0a3f622717b08a1c04d5614f33fd44115cf8a40a
Author: Svetoslav Neykov <sv...@cloudsoftcorp.com>
Date:   2016-10-02T09:20:58Z

    Adds optional task startup jitter
    
    Useful for troubleshooting/testing concurrency related code.

commit c71c896075ac6582d4a10a9bacdd3e294953c129
Author: Svetoslav Neykov <sv...@cloudsoftcorp.com>
Date:   2016-10-02T13:26:49Z

    Logging - link thread name to running task

commit b4fd40d3d1359b3ce3623801f6c72b465a8725cc
Author: Svetoslav Neykov <sv...@cloudsoftcorp.com>
Date:   2016-10-02T09:52:13Z

    Remove duplicate thread renaming
    
    The code in beforeStartAtomicTask overrides the value set here. Keeping the other one as it's called for scheduled tasks as well.

commit 361574c881c215503621d7b5a0a7d52423368b2b
Author: Svetoslav Neykov <sv...@cloudsoftcorp.com>
Date:   2016-10-02T13:19:46Z

    Test Transformer reliability when resolving DSL

----


> The sensor Transformer enricher fails to resolve its targetValue indeterministically.
> -------------------------------------------------------------------------------------
>
>                 Key: BROOKLYN-356
>                 URL: https://issues.apache.org/jira/browse/BROOKLYN-356
>             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|https://github.com/apache/brooklyn-server/blob/b59e7463a9b337c2d0e7931cd420d5bac68d8549/core/src/main/java/org/apache/brooklyn/enricher/stock/Transformer.java#L90-L94] 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
(v6.3.4#6332)