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

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_r85906370
  
    --- Diff: 
camp/camp-brooklyn/src/test/java/org/apache/brooklyn/camp/brooklyn/dsl/DslTest.java
 ---
    @@ -118,39 +160,64 @@ public void runConcurrentWorker(Supplier<Runnable> 
taskSupplier) {
         }
         
         private static class DslTestWorker implements Runnable {
    -        protected TestApplication parent;
    -        protected BrooklynDslDeferredSupplier<?> dsl;
    +        protected final TestApplication parent;
    +        protected final BrooklynDslDeferredSupplier<?> dsl;
    +        protected final Class<?> type;
             protected EntitySpec<TestEntity> childSpec = 
EntitySpec.create(TestEntity.class);
    -        protected Class<?> type;
    -
    +        protected int resolverIterations = MANY_RESOLVER_ITERATIONS;
    +        protected boolean eventually = false;
    +        private boolean wrapInTaskForImmediately = true;
    +        
             public DslTestWorker(TestApplication parent, 
BrooklynDslDeferredSupplier<?> dsl, Class<?> type) {
    -            this.parent = parent;
    -            this.dsl = dsl;
    -            this.type = type;
    +            this.parent = checkNotNull(parent, "parent");
    +            this.dsl = checkNotNull(dsl, "dsl");
    +            this.type = checkNotNull(type, "type");
             }
     
    +        public DslTestWorker resolverIterations(int val) {
    +            resolverIterations = val;
    +            return this;
    +        }
    +        
    +        public DslTestWorker eventually(boolean val) {
    +            eventually = val;
    +            return this;
    +        }
    +        
    +        public DslTestWorker wrapInTaskForImmediately(boolean val) {
    +            wrapInTaskForImmediately = val;
    +            return this;
    +        }
    +        
             @Override
             public void run() {
    -            TestEntity entity = parent.createAndManageChild(childSpec);
    -            for (int i = 0; i < RESOLVER_ITERATIONS; i++) {
    +            TestEntity entity = parent.addChild(childSpec);
    +            for (int i = 0; i < resolverIterations; i++) {
                     preResolve(entity);
    --- End diff --
    
    I'll rename this from "eventually" to "satisfiedAsynchronously".
    
    What "eventually" meant was that the condition for getting the value 
immediately is not yet satisfied; it will become satisfied asynchronously. For 
example, when testing `attributeWhenReady` then another thread sets the 
sensor's value after we have called `execDslEventually` - we expect that method 
to block.
    
    I'll also change the assertions so that we confirm we get a Maybe or the 
real result when calling getImmediately in this situation.


> 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