[
https://issues.apache.org/jira/browse/BROOKLYN-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15721923#comment-15721923
]
Svetoslav Neykov edited comment on BROOKLYN-329 at 12/5/16 10:47 AM:
---------------------------------------------------------------------
Re (2) we tracked this down to a bug in one of the early Openstack Ubuntu cloud
images. A misconfiguration was limiting processes to max 512 threads. Which is
still a lot but Brooklyn will fill it up easily.
Leaving the link to the [ubuntu change
log|https://wiki.ubuntu.com/XenialXerus/ReleaseNotes/ChangeSummary/16.04.1]
which contains the bug description here for future reference.
{noformat}
systemd
1578080
Revert "enable TasksMax= for all services by default, and set it to 512".
Introducing a default
limit on number of threads broke a lot of software which regularly needs more,
such as MySQL
and RabbitMQ, or services that spawn off an indefinite number of subtasks that
are not in a
scope, like LXC or cron. 512 is way too much for most "simple" services, and
it's way too little
for the ones mentioned above. Effective (and much stricter) limits should
instead be put into
units individually. (Closes: #823530, LP: #1578080)
{noformat}
was (Author: svet):
Re (2) we tracked this down to a bug in one of the early Openstack Ubuntu cloud
images. A misconfiguration was limiting processes to max 512 threads. Which is
still a lot but Brooklyn will fill it up easily.
> $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)
