[
https://issues.apache.org/jira/browse/BROOKLYN-375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15595903#comment-15595903
]
Aled Sage commented on BROOKLYN-375:
------------------------------------
The next steps are:
1. attempt to reproduce with {{-XX:SoftRefLRUPolicyMSPerMB=1}}. Assuming that
fixes the problem, publicise this workaround
2. leave the clocker blueprint running for a much longer time with this fix, to
ensure there are no other memory problems in this area
3. look at using a cache (e.g. using guava's cache class) for storing our
tasks, rather than using soft references. We'd evict the old tasks explicitly
(based on least-recently-used) to constrain its size.
4. consider longer term the use of a cache that is backed by the file system
(but that can be deferred).
> Brooklyn intermittently uses high CPU levels and becomes unresponsive
> ---------------------------------------------------------------------
>
> Key: BROOKLYN-375
> URL: https://issues.apache.org/jira/browse/BROOKLYN-375
> Project: Brooklyn
> Issue Type: Bug
> Environment: OSX Sierra, Java 1.7
> Reporter: Duncan Godwin
>
> Intermittently whilst launching a clocker swarm within brooklyn, it uses high
> CPU levels and becomes unresponsive. This was noted when testing failover by
> manally stopping some nodes with `shutdown -h`.
> [jstack 1|https://gist.github.com/drigodwin/c5946d23ed11350f393d9ba9b80a2a2d]
> [jstack 2|https://gist.github.com/drigodwin/5619b02c0c1d53ceb0c99234d8f0dd96]
> [jclouds.debug.log|https://gist.github.com/drigodwin/365d39d216e6a56c634a5020496ef8f1]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
