Hi Alex,
Thanks for your comments
Regarding point 1, I tried combining the `producer` and `sensorMappings`
[1], and this didn't cause the same CPU load, but didn't map the sensor to
'host'. Also, in our use-case this wouldn't work as the `producer`
propagator is in the java code, and the `sensorMapping` propagator is in
the YAML
For point 2, as a quick spike, I simply added `LOG.info("***** EVENT: " +
event);` to Propagator.onEvent(), and could immediately see that the log
was flooded with calls to this method. I'm not entirely sure how we could
set up a call chain here, but will have a look now - any pointers would be
appreciated!
[1]: https://gist.github.com/nakomis/2e37af8d51282004f1c6
Cheers
M
On 10 September 2015 at 14:17, Alex Heneveld (JIRA) <[email protected]> wrote:
>
> [
> https://issues.apache.org/jira/browse/BROOKLYN-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14738724#comment-14738724
> ]
>
> Alex Heneveld commented on BROOKLYN-171:
> ----------------------------------------
>
> Two thoughts:
>
> 1. Can you combine `producer` and `sensorMapping` to get this done with
> one propagator? (Or could propagator easily be changed so this is the
> case.)
>
> 2. Why on earth does this run so much? I'm guessing something there is a
> cyclic dependency in sensor enrichers. This isn't hard to do but in this
> case it looks like there is a bug. Would be worth introducing a call chain
> (or maybe there is the start of one?) for subscriptions so we can log at
> some large depth and explore the cycle, and terminate eventually, because
> it is nasty to debug (and is an exploit in YAML-space). And then of course
> fix the bug causing it in this case.
>
>
> > Mapping propagated sensor causes excessive CPU load
> > ---------------------------------------------------
> >
> > Key: BROOKLYN-171
> > URL: https://issues.apache.org/jira/browse/BROOKLYN-171
> > Project: Brooklyn
> > Issue Type: Bug
> > Reporter: Martin Harris
> >
> > Mapping a propagated sensor using a second propagator will cause
> excessive CPU load, and the sensor will fail to propagate. This can be
> demonstrated using the following YAML:
> > {noformat}
> > location: localhost
> > services:
> > - type: org.apache.brooklyn.entity.stock.BasicApplication
> > brooklyn.children:
> > - type: org.apache.brooklyn.entity.software.base.EmptySoftwareProcess
> > id: childid
> > brooklyn.enrichers:
> > - type: org.apache.brooklyn.enricher.stock.Propagator
> > brooklyn.config:
> > producer: $brooklyn:component("child", "childid")
> > propagating:
> > - $brooklyn:sensor("host.name")
> > - type: org.apache.brooklyn.enricher.stock.Propagator
> > brooklyn.config:
> > sensorMapping:
> > $brooklyn:sensor("host.name"): $brooklyn:sensor("host")
> > {noformat}
> > Running this YAML will cause CPU load on my machine to run to around
> 600% CPU, and cause the Brooklyn console to become unresponsive. The specs
> of my machine are as follows:
> > Model Name: MacBook Pro
> > Model Identifier: MacBookPro11,3
> > Processor Name: Intel Core i7
> > Processor Speed: 2.8 GHz
> > Number of Processors: 1
> > Total Number of Cores: 4
> > L2 Cache (per Core): 256 KB
> > L3 Cache: 6 MB
> > Memory: 16 GB
> > *Context (aka 'Why would you ever want to do this??')*:
> > The Redis cluster propagates the hostname of the master RedisStore up to
> the cluster level [1]. We then added (in the YAML) a propagator with
> `sensorMapping` to map the sensor `host.name` to `host` in order for it
> to be consumed by a third party application (CloudFoundry via the
> Brooklyn-Service-Broker[2])
> > In this scenario (i.e. Redis, deploying to AWS from a rBrooklyn server),
> the server web interface becomes completely unresponsive until the Brooklyn
> process is terminated and restarted
> > [1]:
> https://github.com/apache/incubator-brooklyn/blob/6f15e8a6d61c2e648547cf7faba03fbc06716421/software/nosql/src/main/java/org/apache/brooklyn/entity/nosql/redis/RedisClusterImpl.java#L73-L76
> > [2]: https://github.com/cloudfoundry-incubator/brooklyn-service-broker
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.3.4#6332)
>
--
Martin Harris
Lead Software Engineer
Cloudsoft Corporation Ltd
www.cloudsoftcorp.com
Mobile: +44 (0)7989 047-855
--
Cloudsoft Corporation Limited, Registered in Scotland No: SC349230.
Registered Office: 13 Dryden Place, Edinburgh, EH9 1RP
This e-mail message is confidential and for use by the addressee only. If
the message is received by anyone other than the addressee, please return
the message to the sender by replying to it and then delete the message
from your computer. Internet e-mails are not necessarily secure. Cloudsoft
Corporation Limited does not accept responsibility for changes made to this
message after it was sent.
Whilst all reasonable care has been taken to avoid the transmission of
viruses, it is the responsibility of the recipient to ensure that the
onward transmission, opening or use of this message and any attachments
will not adversely affect its systems or data. No responsibility is
accepted by Cloudsoft Corporation Limited in this regard and the recipient
should carry out such virus and other checks as it considers appropriate.
