[
https://issues.apache.org/jira/browse/BROOKLYN-375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15654248#comment-15654248
]
ASF GitHub Bot commented on BROOKLYN-375:
-----------------------------------------
Github user aledsage commented on a diff in the pull request:
https://github.com/apache/brooklyn-server/pull/412#discussion_r87408752
--- Diff:
utils/common/src/test/java/org/apache/brooklyn/util/javalang/MemoryUsageTrackerTest.java
---
@@ -82,7 +82,7 @@ private long sizeOfActiveReferences(List<Maybe<byte[]>>
references) {
return size;
}
- @Test(groups="Integration")
+ @Test(groups="Live")
--- End diff --
I didn't realise that apache infra was running our integration tests.
Thanks for the link!
No strong feelings from me. Or could mark is as group "Broken" until we get
to the bottom of it. I'll play around in another PR at a possible fix. Will
ping you when that's done!
Here's the output from apache infra's run. Note that the test took `1454694
ms`, compared to 3 seconds on my laptop (I run java 7). Note how many 1M
objects we've created! I therefore believe the first (i.e. the one we check)
was not being deleted, but lots of others were. We could check for any absent,
rather than just the first.
```
2016-11-10 09:38:30,153 INFO First soft reference cleared after 1000001 1M
blocks created; 999628 of them cleared
2016-11-10 09:38:30,158 INFO TESTNG FAILED: "Surefire test" -
org.apache.brooklyn.util.javalang.MemoryUsageTrackerTest.testSoftUsageAndClearance()
finished in 1454694 ms
java.lang.AssertionError: Should have had less than 10% free memory before
clearance, had 266 MB / 716 MB expected [true] but found [false]
at
org.apache.brooklyn.util.javalang.MemoryUsageTrackerTest.testSoftUsageAndClearance(MemoryUsageTrackerTest.java:104)
```
I wonder if it's related to @drigodwin's change in
https://github.com/apache/brooklyn-server/blob/master/parent/pom.xml#L691 to
add `-XX:SoftRefLRUPolicyMSPerMB=1` (as discussed in
https://issues.apache.org/jira/browse/BROOKLYN-375). That could change the
behaviour we see, for when and how much is collected. But I wouldn't have
thought so, because that just changes the behaviour on collection (and
shouldn't trigger a collection before one is really needed).
> 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)
