[
https://issues.apache.org/jira/browse/BROOKLYN-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15717920#comment-15717920
]
Aled Sage commented on BROOKLYN-329:
------------------------------------
The "immediate evaluation" should never create tasks, unless it absolutely has
to (e.g. only if the DSL or whatever it's calling really needs to spawn a new
thread to figure out the value).
The "immediate evaluation" was added in response to some crazy thread usage.
There were two bad things:
1. As described in https://issues.apache.org/jira/browse/BROOKLYN-356, when
wanting the value "immediately" (or absent), we previously spawned a task,
waited 250ms for it to complete, and then aborted it. On a heavily loaded
server, it might not complete within that time so we'd get back "absent" and
then potentially never evaluate it again.
2. The excessive thread usage was causing {{OutOfMemoryError}} in an Ubuntu
Xenial environment when trying to deploy large blueprints (e.g. kubernetes).
I'm not sure if the customer has shared any more details on that - I can't see
any associated bug reports. I think that [~svet] and [~geomacy] may know more
details.
For (2), our evaluation of DSLs used to consume a lot of threads. Particularly
things like {{$brooklyn:formatString}} evaluating its parameters of type
{{$brooklyn:attributeWhenReady}} would result in several threads being used. If
you multiplied that up (e.g. several shell.env parameters per entity, and many
entities), it could reach stupidly high numbers I believe.
> $brooklyn:config hangs, rather than getting default brooklyn.parameter value
> ----------------------------------------------------------------------------
>
> Key: BROOKLYN-329
> URL: https://issues.apache.org/jira/browse/BROOKLYN-329
> Project: Brooklyn
> Issue Type: Bug
> Reporter: Aled Sage
> Priority: Minor
>
> Using 0.10.0-SNAPSHOT...
> I wrote a YAML entity where CouchDB was configured with an initial
> username/password, and another app that included CouchDB would inject it.
> In each blueprint, I defined a brooklyn.parameter with a default value for
> the username/password. I used the same config key name in each.
> However, when I ran my blueprint it hung. The CouchDB was waiting forever for
> the username/password config value.
> I recreated this behaviour in the simpler test case below (which I'll add to
> {{ConfigParametersYamlTest}}).
> The workaround is to use a different name for the config key in each
> blueprint. For example, in the outer blueprint above if youchange the name to
> {{my.param.key2}} then the test passes.
> Debugging it, one surprising thing I noticed is that {{scopeRoot()}}
> evaluates to be "entity-with-tests" rather than {{wrapper-entity}}.
> {noformat}
> public void testConfigParameterPassedFromOuterConfigParameter() throws
> Exception {
> addCatalogItems(
> "brooklyn.catalog:",
> " itemType: entity",
> " items:",
> " - id: entity-with-keys",
> " item:",
> " type: "+TestEntity.class.getName(),
> " brooklyn.parameters:",
> " - name: my.param.key",
> " type: string",
> " default: myDefaultVal",
> " brooklyn.config:",
> " my.other.key: $brooklyn:config(\"my.param.key\")");
> addCatalogItems(
> "brooklyn.catalog:",
> " itemType: entity",
> " items:",
> " - id: wrapper-entity",
> " item:",
> " brooklyn.parameters:",
> " - name: my.param.key",
> " type: string",
> " default: myDefaultValInOuter",
> " type: entity-with-keys",
> " brooklyn.config:",
> " my.param.key:
> $brooklyn:scopeRoot().config(\"my.param.key\")");
>
> String yaml = Joiner.on("\n").join(
> "services:",
> "- type: wrapper-entity");
>
> Entity app = createStartWaitAndLogApplication(yaml);
> final TestEntity entity = (TestEntity)
> Iterables.getOnlyElement(app.getChildren());
> Asserts.assertReturnsEventually(new Runnable() {
> public void run() {
>
> assertEquals(entity.config().get(ConfigKeys.newStringConfigKey("my.other.key")),
> "myDefaultValInOuter");
> }},
> Asserts.DEFAULT_LONG_TIMEOUT);
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
