Return-Path: <dev-return-19799-archive-asf-public=cust-asf.ponee.io@brooklyn.apache.org>
X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io
Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io
Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183])
	by cust-asf2.ponee.io (Postfix) with ESMTP id 39216200BD4
	for <archive-asf-public-internal@cust-asf2.ponee.io>; Wed, 26 Oct 2016 21:45:01 +0200 (CEST)
Received: by cust-asf.ponee.io (Postfix)
	id 37EC4160AE1; Wed, 26 Oct 2016 19:45:01 +0000 (UTC)
Delivered-To: archive-asf-public@cust-asf.ponee.io
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by cust-asf.ponee.io (Postfix) with SMTP id 764B3160B09
	for <archive-asf-public@cust-asf.ponee.io>; Wed, 26 Oct 2016 21:45:00 +0200 (CEST)
Received: (qmail 78837 invoked by uid 500); 26 Oct 2016 19:44:59 -0000
Mailing-List: contact dev-help@brooklyn.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@brooklyn.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@brooklyn.apache.org>
List-Post: <mailto:dev@brooklyn.apache.org>
List-Id: <dev.brooklyn.apache.org>
Reply-To: dev@brooklyn.apache.org
Delivered-To: mailing list dev@brooklyn.apache.org
Received: (qmail 78204 invoked by uid 99); 26 Oct 2016 19:44:59 -0000
Received: from arcas.apache.org (HELO arcas) (140.211.11.28)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 26 Oct 2016 19:44:59 +0000
Received: from arcas.apache.org (localhost [127.0.0.1])
	by arcas (Postfix) with ESMTP id A4FA72C2AB8
	for <dev@brooklyn.apache.org>; Wed, 26 Oct 2016 19:44:58 +0000 (UTC)
Date: Wed, 26 Oct 2016 19:44:58 +0000 (UTC)
From: "ASF GitHub Bot (JIRA)" <jira@apache.org>
To: dev@brooklyn.apache.org
Message-ID: <JIRA.13009042.1475312740000.92890.1477511098672@Atlassian.JIRA>
In-Reply-To: <JIRA.13009042.1475312740000@Atlassian.JIRA>
References: <JIRA.13009042.1475312740000@Atlassian.JIRA> <JIRA.13009042.1475312740273@arcas>
Subject: [jira] [Commented] (BROOKLYN-356) The sensor Transformer enricher
 fails to resolve its targetValue indeterministically.
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394
archived-at: Wed, 26 Oct 2016 19:45:01 -0000


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

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_r85102209
  
    --- Diff: camp/camp-brooklyn/src/main/java/org/apache/brooklyn/camp/brooklyn/spi/dsl/methods/BrooklynDslCommon.java ---
    @@ -525,6 +590,12 @@ public DslExternal(String providerName, String key) {
             }
     
             @Override
    +        public final Maybe<Object> getImmediately() {
    --- End diff --
    
    Could call this from within the `newTask` body.


> 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)