[
https://issues.apache.org/jira/browse/BROOKLYN-356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15626105#comment-15626105
]
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_r85981351
--- Diff:
camp/camp-brooklyn/src/main/java/org/apache/brooklyn/camp/brooklyn/spi/dsl/methods/BrooklynDslCommon.java
---
@@ -525,15 +583,20 @@ public DslExternal(String providerName, String key) {
}
@Override
+ public final Maybe<Object> getImmediately() {
+ ManagementContextInternal managementContext =
DslExternal.managementContext();
+ return
Maybe.<Object>of(managementContext.getExternalConfigProviderRegistry().getConfig(providerName,
key));
--- End diff --
@neykov This is an interesting one! The
`managementContext.getExternalConfigProviderRegistry().getConfig(...)` is
calling a different getConfig whose javadoc simply says:
```
/**
* Searches the named {@link ExternalConfigSupplier} for the config
value associated with the specified key.
* Quietly returns <code>null</code> if no config exists for the
specified key.
* Throws {@link IllegalArgumentException} if no {@link
ExternalConfigSupplier} exists for the passed name.
*/
```
The existing implementation delegates to `ExternalConfigSupplier.get(key)`.
There is no guidance on that whether the call could be blocking, or should
return reasonably promptly.
I'd assume it would call out to things like Vault, and would return the
value that currently exists or null. Such calls will not be super-fast, but
should not be blocked waiting for other entities either.
I therefore think this is good enough, to just call getConfig without
wrapping it in another task for timeout-purposes.
If it's not good enough, then we should really change `DslExternal` back so
that it doesn't even try to support `getImmediately()`. Or we could try to
change the interface of `ExternalConfigSupplierRegistry` etc.
> 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)
