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

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_r81934135
  
    --- 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)
    +    public void testTransformerResolvesResolvableValuesIntegration() {
    --- End diff --
    
    Nice test. Without the jitter, I ran it with `invocationCount=100` and it 
failed 2 out of 100 times with errors like:
    
        java.lang.AssertionError: entity=Application[s01l91es]; 
attribute=Sensor: port.transformed (java.lang.String) expected [10889] but 
found [null]



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

Reply via email to