brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Heneveld (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (BROOKLYN-171) Mapping propagated sensor causes excessive CPU load
Date Thu, 10 Sep 2015 13:49:46 GMT

    [ https://issues.apache.org/jira/browse/BROOKLYN-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14738771#comment-14738771
] 

Alex Heneveld commented on BROOKLYN-171:
----------------------------------------

In `LocalSubscriptionManager.publish(..)` there is a block of comments about setting additional
tags.

We could add a tag `subscriptionChain` for any custom information.

However if you can run the test case in java have it store the value of `Tasks.current()`
to a local variable so you can inspect it; we may already have `Task.submittedBy` set (this
happens automatically when a task submits a task).  It's going to be an expensive way to record
the depth (though it could be optimized if the code which sets submitted by also sets depth
and looks up depth in the caller).  Then add a warning as `depth>0 && depth % 1000
== 0` and throw at `depth >= 10000` in the `publish()` block.

For logging maybe add a log trace in the `publish` method which always runs and which we can
turn on as needed, and for the warnings above we could log debug the submission history (in
addition to a log warn).

(Just some thoughts.)

As for the combined propagator not working the code in `Propagator` tries to support it, but
it could well be down to sensors not being equal (i.e. if one is anonymous).  A breakpoint
in its `setEntity` should tell you if the sensor mapping is wrong.

> 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)

Mime
View raw message