[GitHub] brooklyn-server pull request #480: Config self reference fix

[aledsage <gi...@git.apache.org>]

Github user aledsage commented on a diff in the pull request:

    https://github.com/apache/brooklyn-server/pull/480#discussion_r101862310
  
    --- Diff: core/src/main/java/org/apache/brooklyn/util/core/task/ValueResolver.java ---
    @@ -352,33 +357,51 @@ public T get() {
             
             //if the expected type is a closure or map and that's what we have, we're done (or if it's null);
             //but not allowed to return a future or DeferredSupplier as the resolved value
    -        if (v==null || (!forceDeep && type.isInstance(v) && !Future.class.isInstance(v) && !DeferredSupplier.class.isInstance(v)))
    +        if (v==null || (!forceDeep && type.isInstance(v) && !Future.class.isInstance(v) && !DeferredSupplier.class.isInstance(v) && !TaskFactory.class.isInstance(v)))
                 return Maybe.of((T) v);
             
             try {
    -            if (immediately && v instanceof ImmediateSupplier) {
    -                final ImmediateSupplier<?> supplier = (ImmediateSupplier<?>) v;
    +            if (isEvaluatingImmediately() && v instanceof ImmediateSupplier) {
    +                final ImmediateSupplier<Object> supplier = (ImmediateSupplier<Object>) v;
                     try {
    -                    Maybe<?> result = supplier.getImmediately();
    +                    Maybe<Object> result = exec.getImmediately(supplier);
                         
                         // Recurse: need to ensure returned value is cast, etc
                         return (result.isPresent())
                                 ? recursive
                                     ? new ValueResolver(result.get(), type, this).getMaybe()
                                     : result
    -                            : Maybe.<T>absent();
    +                            : result;
                     } catch (ImmediateSupplier.ImmediateUnsupportedException e) {
                         log.debug("Unable to resolve-immediately for "+description+" ("+v+"); falling back to executing with timeout", e);
                     }
                 }
                 
    +            // TODO if evaluating immediately should use a new ExecutionContext.submitImmediate(...)
    +            // and sets a timeout but which wraps a task but does not spawn a new thread
    +            
    +            if ((v instanceof TaskFactory<?>) && !(v instanceof DeferredSupplier)) {
    --- End diff --
    
    I'd add something like the following to `ValueResolverTest`:
    ```
        public void testTaskFactoryGet() {
            TaskFactory<TaskAdaptable<String>> taskFactory = new TaskFactory<TaskAdaptable<String>>() {
                @Override public TaskAdaptable<String> newTask() {
                    return new BasicTask<>(Callables.returning("myval"));
                }
            };
            String result = Tasks.resolving(taskFactory).as(String.class).context(app).get();
            assertEquals(result, "myval");
        }
        
        public void testTaskFactoryGetImmediately() {
            TaskFactory<TaskAdaptable<String>> taskFactory = new TaskFactory<TaskAdaptable<String>>() {
                @Override public TaskAdaptable<String> newTask() {
                    return new BasicTask<>(Callables.returning("myval"));
                }
            };
            String result = Tasks.resolving(taskFactory).as(String.class).context(app).immediately(true).get();
            assertEquals(result, "myval");
        }
        
        public void testTaskFactoryGetImmediatelyDoesNotBlock() {
            final AtomicBoolean executing = new AtomicBoolean();
            TaskFactory<TaskAdaptable<String>> taskFactory = new TaskFactory<TaskAdaptable<String>>() {
                @Override public TaskAdaptable<String> newTask() {
                    return new BasicTask<>(new Callable<String>() {
                        public String call() {
                            executing.set(true);
                            try {
                                Time.sleep(Duration.ONE_MINUTE);
                                return "myval";
                            } finally {
                                executing.set(false);
                            }
                        }});
                }
            };
            Maybe<String> result = Tasks.resolving(taskFactory).as(String.class).context(app).immediately(true).getMaybe();
            assertTrue(result.isAbsent(), "result="+result);
            Asserts.succeedsEventually(new Runnable() {
                public void run() {
                    assertFalse(executing.get());
                }
            });
        }
    ```
    However, the last assertion fails - using `immediately()` with `TaskFactory` is dangerous because the task is left running. It is particularly dangerous because `immediately()` is most often used when it's being called regularly (e.g. the rest api wants to list all the config values).
    
    Whose responsibility is it to cancel the task? (It feels like the task instance is buried inside the `ValueResolver`, so it would be hard for the caller to get hold of it to cancel it). Should the `ValueResolver` cancel the task it created, if using `immediately()`?
    
    What are the use-cases for passing a `TaskFactory` into the `ValueResolver`?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---