[
https://issues.apache.org/jira/browse/OAK-4966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15633238#comment-15633238
]
Michael Dürig commented on OAK-4966:
------------------------------------
Nice, I like the way {{GCMemoryBarrier.checkMemory()}} is implemented now! One
small oversight: {{GCMemoryBarrier.getMemoryPool()}} should check
{{MemoryPoolMXBean.isCollectionUsageThresholdSupported()}} instead of
{{MemoryPoolMXBean.isUsageThresholdSupported()}}.
Also I think the various accessors of the gc memory threshold should mention
that this number is a percentage. And finally a bit of Javadoc on
{{GCMemoryBarrier}} would be nice ;-)
> Re-introduce a blocker for compaction based on available heap
> -------------------------------------------------------------
>
> Key: OAK-4966
> URL: https://issues.apache.org/jira/browse/OAK-4966
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
> Reporter: Alex Parvulescu
> Assignee: Alex Parvulescu
> Fix For: 1.6, 1.5.13
>
> Attachments: OAK-4966-jmx-notification-v2.patch,
> OAK-4966-jmx-notification.patch, OAK-4966.patch
>
>
> As seen in a local test, running compaction on a tight heap can lead to
> OOMEs. There used to be a best effort barrier against this situation 'not
> enough heap for compaction', but we removed it with the compaction maps.
> I think it makes sense to add it again based on the max size of some of the
> caches: segment cache {{256MB}} by default [0] and some writer caches which
> can go up to {{2GB}} all combined [1] and probably others I missed.
> [0]
> https://github.com/apache/jackrabbit-oak/blob/trunk/oak-segment-tar/src/main/java/org/apache/jackrabbit/oak/segment/SegmentCache.java#L48
> [1]
> https://github.com/apache/jackrabbit-oak/blob/trunk/oak-segment-tar/src/main/java/org/apache/jackrabbit/oak/segment/WriterCacheManager.java#L50
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
