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

Reply via email to