[ https://issues.apache.org/jira/browse/BROOKLYN-356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15609464#comment-15609464 ]
ASF GitHub Bot commented on BROOKLYN-356: ----------------------------------------- Github user geomacy commented on a diff in the pull request: https://github.com/apache/brooklyn-server/pull/390#discussion_r85103885 --- Diff: camp/camp-brooklyn/src/main/java/org/apache/brooklyn/camp/brooklyn/spi/dsl/methods/DslComponent.java --- @@ -303,6 +330,12 @@ public DslConfigSupplier(DslComponent component, String keyName) { } @Override + public final Maybe<Object> getImmediately() { + Entity targetEntity = component.get(); --- End diff -- should this be `component.getImmediately().get()`, as in the `attributeWhenReady` above? > 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)