[
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 <[email protected]>
Date: 2016-10-02T09:20:58Z
Adds optional task startup jitter
Useful for troubleshooting/testing concurrency related code.
commit c71c896075ac6582d4a10a9bacdd3e294953c129
Author: Svetoslav Neykov <[email protected]>
Date: 2016-10-02T13:26:49Z
Logging - link thread name to running task
commit b4fd40d3d1359b3ce3623801f6c72b465a8725cc
Author: Svetoslav Neykov <[email protected]>
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 <[email protected]>
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)
