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

    https://github.com/apache/brooklyn-server/pull/480#discussion_r101864959
  
    --- Diff: 
core/src/test/java/org/apache/brooklyn/core/entity/EntityConfigTest.java ---
    @@ -244,59 +252,152 @@ public void 
testGetConfigMapWithSubValueAsStringNotCoerced() throws Exception {
         // of the previous "test.confMapThing.obj".
         //
         // Presumably an earlier call to task.get() timed out, causing it to 
cancel the task?
    +    // Alex: yes, a task.cancel is performed for maps in
    +    // 
AbstractEntity$BasicConfigurationSupport(AbstractConfigurationSupportInternal).getNonBlockingResolvingStructuredKey(ConfigKey<T>)
    
    + 
    +    //
         // I (Aled) question whether we want to support passing a task (rather 
than a 
         // DeferredSupplier or TaskFactory, for example). Our 
EntitySpec.configure is overloaded
         // to take a Task, but that feels wrong!?
    -    @Test(groups="Broken")
    -    public void testGetTaskNonBlocking() throws Exception {
    -        final CountDownLatch latch = new CountDownLatch(1);
    -        Task<String> task = Tasks.<String>builder().body(
    +    //
    +    // If starting clean I (Alex) would agree, we should use TaskFactory. 
However the
    --- End diff --
    
    I suspect our `DependentConfiguration` class could do with a re-write, but 
not sure off-hand exactly what it should look like. And doesn't feel like it's 
worth doing right now.
    
    It's trick because `WaitInTaskForAttributeReady extends Callable` expects 
to subscribe to (multiple) sensors, and then block for a matching value. We 
could most likely re-implement that (see below).
    
    Using a `TaskFactory` would be tricky, because we only want to do the 
subscriptions once. It is conceptually a single "task" (i.e. we don't want to 
do the subscriptions multiple times).
    
    My gut-feel is therefore we could implement it as a `DeferredSupplier`. 
When first called (or maybe when created), it would create the subscriptions. 
The thread executing the `get` would just be blocking on a `CountDownLatch`, 
which would be set by the subscription callbacks when the value was available 
(or when the entity had failed). Multiple calls to `get()` would share the same 
instance, so would all be blocking on the same thing.


---
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 infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Reply via email to