Aled Sage created BROOKLYN-309:
----------------------------------
Summary: shell.env (and other MapConfigKeys) fail for values that
include tasks
Key: BROOKLYN-309
URL: https://issues.apache.org/jira/browse/BROOKLYN-309
Project: Brooklyn
Issue Type: Bug
Reporter: Aled Sage
In very recent Brooklyn 0.10.0-SNAPSHOT...
Calling {{entity.config().getNonBlocking(key)}}, where key is of type
{{MapConfigKey}}, fails for certain types of values. It causes subsequent calls
to {{entity.config().get(key)}} to fail.
For example, see {{EntityConfigTest.testGetTaskNonBlocking()}}, where the key's
value is a {{Task}}.
It seems that the task was executed as a result of getNonBlocking(), but was
then cancelled after a short timeout. When we subsequently try to block for the
task to complete, it immediately fails due to the cancellation.
This particular test used to pass (e.g. with commit
56fcc1632ea4f5ac7f4136a7e04fabf501337540 or earlier). It failed after the
rename of CONF_MAP_THING_OBJ to CONF_MAP_OBJ_THING, which suggests there was an
underlying problem that was masked by the unfortunate naming of the previous
"test.confMapThing.obj".
A related change was
https://github.com/apache/brooklyn-server/commit/8bfff1635c77affa19b9a33522ac1ab2ae6d2c8d.
Prior to this, the call to {{getNonBlocking(key}} would always return null for
a {{MapConfigKey}}. This meant we would not have attempted to execute the task
(and therefore would not have subsequently cancelled the task).
We hit the same problem when implementing and using the new YAML DSL
functionality for invoking effectors. If that is used inside {{shell.env}}
(which is a MapConfigKey) then our early call to getNonBlocking (done during
config validation) means our later call to config().get() fails.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
