brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (BROOKLYN-356) The sensor Transformer enricher fails to resolve its targetValue indeterministically.
Date Wed, 05 Oct 2016 09:32:20 GMT

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

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/365#discussion_r81934241
  
    --- Diff: camp/camp-brooklyn/src/test/java/org/apache/brooklyn/camp/brooklyn/enricher/TransformerEnricherWithDslTest.java
---
    @@ -0,0 +1,78 @@
    +/*
    + * Copyright 2016 The Apache Software Foundation.
    + *
    + * Licensed under the Apache License, Version 2.0 (the "License");
    + * you may not use this file except in compliance with the License.
    + * You may obtain a copy of the License at
    + *
    + *      http://www.apache.org/licenses/LICENSE-2.0
    + *
    + * Unless required by applicable law or agreed to in writing, software
    + * distributed under the License is distributed on an "AS IS" BASIS,
    + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
    + * See the License for the specific language governing permissions and
    + * limitations under the License.
    + */
    +package org.apache.brooklyn.camp.brooklyn.enricher;
    +
    +import static org.testng.Assert.assertEquals;
    +
    +import org.apache.brooklyn.api.sensor.AttributeSensor;
    +import org.apache.brooklyn.api.sensor.EnricherSpec;
    +import org.apache.brooklyn.camp.brooklyn.spi.dsl.methods.BrooklynDslCommon;
    +import org.apache.brooklyn.core.entity.EntityAsserts;
    +import org.apache.brooklyn.core.sensor.Sensors;
    +import org.apache.brooklyn.core.test.BrooklynAppUnitTestSupport;
    +import org.apache.brooklyn.enricher.stock.Transformer;
    +import org.slf4j.Logger;
    +import org.slf4j.LoggerFactory;
    +import org.testng.annotations.Test;
    +
    +public class TransformerEnricherWithDslTest extends BrooklynAppUnitTestSupport {
    +    private static final Logger LOG = LoggerFactory.getLogger(TransformerEnricherWithDslTest.class);
    +
    +    int START_PORT = 10000;
    +
    +    @Test(groups="Broken")
    +    public void testTransformerResolvesResolvableValues() {
    +        testTransformerResolvesResolvableValues(START_PORT, 200);
    +    }
    +
    +    @Test(groups={"Integration", "Broken"}, invocationCount=10)
    --- End diff --
    
    Worth including a comment above the test that points people to https://issues.apache.org/jira/browse/BROOKLYN-356


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

Mime
View raw message