[
https://issues.apache.org/jira/browse/BROOKLYN-356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15609472#comment-15609472
]
ASF GitHub Bot commented on BROOKLYN-356:
-----------------------------------------
Github user geomacy commented on a diff in the pull request:
https://github.com/apache/brooklyn-server/pull/390#discussion_r85193147
--- 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 --
Do you not want to do this under an "if(eventually)"?
> 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)
