[
https://issues.apache.org/jira/browse/OAK-4966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15632866#comment-15632866
]
Alex Parvulescu commented on OAK-4966:
--------------------------------------
re. {{MemoryNotificationInfo.MEMORY_COLLECTION_THRESHOLD_EXCEEDED}} very
interesting point. I've switched over to this notification which also removes
our direct dependency to FELIX-5394.
re. {{GCMemoryBarrier.checkMemory()}} yes unfortunately. there might be any
number of listeners and any of them could change the threshold notification.
while there's no guarantee that someone would not actually disable it, at the
very least we can prepare against an overflow of uninteresting notifications.
I've dug around a bit and found something that looks better re. the memory
values (seems there's data attached to the notification itself we can use).
In the current form it is expected that a listener is created for each
compaction run, and not reused. if it does raise the flag, compaction will be
canceled so I'm not really expecting this to be a dynamic barrier (flag should
be reset on the next run only, and even if theoretically it could be reset from
the {{checkMemory()}} method itself, the probability of this happening is
pretty small).
> 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)
