Return-Path: 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 B6A3B200BB3 for ; Wed, 2 Nov 2016 11:03:01 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id B5444160AEA; Wed, 2 Nov 2016 10:03: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 07C78160B0A for ; Wed, 2 Nov 2016 11:03:00 +0100 (CET) Received: (qmail 94726 invoked by uid 500); 2 Nov 2016 10:02:59 -0000 Mailing-List: contact dev-help@brooklyn.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@brooklyn.apache.org Delivered-To: mailing list dev@brooklyn.apache.org Received: (qmail 94382 invoked by uid 99); 2 Nov 2016 10:02:59 -0000 Received: from arcas.apache.org (HELO arcas) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 02 Nov 2016 10:02:59 +0000 Received: from arcas.apache.org (localhost [127.0.0.1]) by arcas (Postfix) with ESMTP id 354702C0087 for ; Wed, 2 Nov 2016 10:02:59 +0000 (UTC) Date: Wed, 2 Nov 2016 10:02:59 +0000 (UTC) From: "ASF GitHub Bot (JIRA)" To: dev@brooklyn.apache.org Message-ID: In-Reply-To: References: 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, 02 Nov 2016 10:03:01 -0000 [ https://issues.apache.org/jira/browse/BROOKLYN-356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15628438#comment-15628438 ] ASF GitHub Bot commented on BROOKLYN-356: ----------------------------------------- Github user aledsage commented on a diff in the pull request: https://github.com/apache/brooklyn-server/pull/390#discussion_r86106651 --- Diff: camp/camp-brooklyn/src/main/java/org/apache/brooklyn/camp/brooklyn/spi/dsl/methods/DslComponent.java --- @@ -340,9 +360,9 @@ public DslConfigSupplier(DslComponent component, String keyName) { public final Maybe getImmediately() { Maybe targetEntityMaybe = component.getImmediately(); if (targetEntityMaybe.isAbsent()) return Maybe.absent("Target entity not available"); - Entity targetEntity = targetEntityMaybe.get(); + EntityInternal targetEntity = (EntityInternal) targetEntityMaybe.get(); - return Maybe.of(targetEntity.getConfig(ConfigKeys.newConfigKey(Object.class, keyName))); + return targetEntity.config().getNonBlocking(ConfigKeys.newConfigKey(Object.class, keyName)); --- End diff -- Yes, I'd updated `AbstractConfigurationSupportInternal` line 142 to use `.immediately(true)`, so I hope that covers the case of `getNonBlockingResolvingSimple`. I didn't want to touch the "structure key" code. We should probably change that at some point to go through ValueResolver, even if that still ends up scheduling it in a task. I therefore think this comment has been addressed. Am I missing something? > 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)