[
https://issues.apache.org/jira/browse/BROOKLYN-356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15625489#comment-15625489
]
ASF GitHub Bot commented on BROOKLYN-356:
-----------------------------------------
Github user neykov commented on a diff in the pull request:
https://github.com/apache/brooklyn-server/pull/390#discussion_r85929615
--- Diff:
core/src/test/java/org/apache/brooklyn/util/core/task/ValueResolverTest.java ---
@@ -69,46 +59,65 @@ public void testTimeoutBig() {
Assert.assertEquals(result.get(), "foo");
}
- public void testNoExecutionContextOnCompleted() {
+ public void testCompletedTaskReturnsResultImmediately() {
+ // Call ValueResolver.getMaybe() from this thread, which has no
execution context.
+ // However, the task has already been submitted and we have waited
for it to complete.
+ // Therefore the ValueResolver can simply check for task.isDone()
and return its result immediately.
Task<String> t = newSleepTask(Duration.ZERO, "foo");
app.getExecutionContext().submit(t).getUnchecked();
Maybe<String> result =
Tasks.resolving(t).as(String.class).timeout(Duration.ZERO).getMaybe();
Assert.assertEquals(result.get(), "foo");
}
- public static Throwable assertThrowsOnMaybe(ValueResolver<?> result) {
- try {
- result = result.clone();
- result.getMaybe();
- Assert.fail("should have thrown");
- return null;
- } catch (Exception e) { return e; }
+ public void testUnsubmittedTaskWhenNoExecutionContextFails() {
+ // ValueResolver.getMaybe() is called with no execution context.
Therefore it will not execute the task.
+ Task<String> t = newSleepTask(Duration.ZERO, "foo");
+ Maybe<String> result =
Tasks.resolving(t).as(String.class).timeout(Duration.ZERO).getMaybe();
+
+ Assert.assertTrue(result.isAbsent(), "result="+result);
+ Exception exception = ((Maybe.Absent<?>)result).getException();
--- End diff --
Can use `Maybe.getException(result)`.
> 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)
