You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-issues@jackrabbit.apache.org by "Michael Dürig (JIRA)" <ji...@apache.org> on 2018/10/19 13:17:00 UTC
[jira] [Comment Edited] (OAK-7838) oak-run check crashes JVM
[ https://issues.apache.org/jira/browse/OAK-7838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16656792#comment-16656792 ]
Michael Dürig edited comment on OAK-7838 at 10/19/18 1:16 PM:
--------------------------------------------------------------
Committed a test case at http://svn.apache.org/viewvc?rev=1844342&view=rev
{noformat}
java.lang.OutOfMemoryError: unable to create new native thread
at java.lang.Thread.start0(Native Method)
at java.lang.Thread.start(Thread.java:714)
at java.util.concurrent.ThreadPoolExecutor.addWorker(ThreadPoolExecutor.java:950)
at java.util.concurrent.ThreadPoolExecutor.ensurePrestart(ThreadPoolExecutor.java:1587)
at java.util.concurrent.ScheduledThreadPoolExecutor.delayedExecute(ScheduledThreadPoolExecutor.java:334)
at java.util.concurrent.ScheduledThreadPoolExecutor.scheduleWithFixedDelay(ScheduledThreadPoolExecutor.java:597)
at org.apache.jackrabbit.oak.segment.file.Scheduler.scheduleWithFixedDelay(Scheduler.java:138)
at org.apache.jackrabbit.oak.segment.CommitsTracker.<init>(CommitsTracker.java:63)
at org.apache.jackrabbit.oak.segment.SegmentNodeStoreStats.<init>(SegmentNodeStoreStats.java:70)
at org.apache.jackrabbit.oak.segment.SegmentNodeStore.<init>(SegmentNodeStore.java:163)
at org.apache.jackrabbit.oak.segment.SegmentNodeStore.<init>(SegmentNodeStore.java:61)
at org.apache.jackrabbit.oak.segment.SegmentNodeStore$SegmentNodeStoreBuilder.build(SegmentNodeStore.java:119)
at org.apache.jackrabbit.oak.segment.file.tooling.ConsistencyChecker.checkConsistency(ConsistencyChecker.java:191)
at org.apache.jackrabbit.oak.segment.tool.Check.run(Check.java:243)
at org.apache.jackrabbit.oak.segment.file.tooling.CheckInvalidRepositoryTest.testLargeJournal(CheckInvalidRepositoryTest.java:252)
{noformat}
was (Author: mduerig):
Committed a test case at http://svn.apache.org/viewvc?rev=1844342&view=rev:
{noformat}
java.lang.OutOfMemoryError: unable to create new native thread
at java.lang.Thread.start0(Native Method)
at java.lang.Thread.start(Thread.java:714)
at java.util.concurrent.ThreadPoolExecutor.addWorker(ThreadPoolExecutor.java:950)
at java.util.concurrent.ThreadPoolExecutor.ensurePrestart(ThreadPoolExecutor.java:1587)
at java.util.concurrent.ScheduledThreadPoolExecutor.delayedExecute(ScheduledThreadPoolExecutor.java:334)
at java.util.concurrent.ScheduledThreadPoolExecutor.scheduleWithFixedDelay(ScheduledThreadPoolExecutor.java:597)
at org.apache.jackrabbit.oak.segment.file.Scheduler.scheduleWithFixedDelay(Scheduler.java:138)
at org.apache.jackrabbit.oak.segment.CommitsTracker.<init>(CommitsTracker.java:63)
at org.apache.jackrabbit.oak.segment.SegmentNodeStoreStats.<init>(SegmentNodeStoreStats.java:70)
at org.apache.jackrabbit.oak.segment.SegmentNodeStore.<init>(SegmentNodeStore.java:163)
at org.apache.jackrabbit.oak.segment.SegmentNodeStore.<init>(SegmentNodeStore.java:61)
at org.apache.jackrabbit.oak.segment.SegmentNodeStore$SegmentNodeStoreBuilder.build(SegmentNodeStore.java:119)
at org.apache.jackrabbit.oak.segment.file.tooling.ConsistencyChecker.checkConsistency(ConsistencyChecker.java:191)
at org.apache.jackrabbit.oak.segment.tool.Check.run(Check.java:243)
at org.apache.jackrabbit.oak.segment.file.tooling.CheckInvalidRepositoryTest.testLargeJournal(CheckInvalidRepositoryTest.java:252)
{noformat}
> oak-run check crashes JVM
> -------------------------
>
> Key: OAK-7838
> URL: https://issues.apache.org/jira/browse/OAK-7838
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: run, segment-tar
> Reporter: Michael Dürig
> Assignee: Michael Dürig
> Priority: Major
> Fix For: 1.10
>
>
> I had a case where running {{oak-run check}} on a repository with many revisions would reliably crash the JVM.
> Apparently there is a problem with the {{Scheduler}} instances in {{org.apache.jackrabbit.oak.segment.CommitsTracker}}: when many instances of that class are created in fast succession it will leave many daemon threads lingering around for a while. In my case this was sufficient to kill the JVM.
> To verify I simply removed the scheduler and everything was just fine:
> {code}
> ===================================================================
> --- oak-segment-tar/src/main/java/org/apache/jackrabbit/oak/segment/CommitsTracker.java (date 1539358293000)
> +++ oak-segment-tar/src/main/java/org/apache/jackrabbit/oak/segment/CommitsTracker.java (date 1539670356000)
> @@ -19,8 +19,6 @@
> package org.apache.jackrabbit.oak.segment;
> -import static java.util.concurrent.TimeUnit.MINUTES;
> -
> import java.io.Closeable;
> import java.util.HashMap;
> import java.util.Map;
> @@ -29,7 +27,6 @@
> import java.util.stream.Stream;
> import com.googlecode.concurrentlinkedhashmap.ConcurrentLinkedHashMap;
> -import org.apache.jackrabbit.oak.segment.file.Scheduler;
> /**
> * A simple tracker for the source of commits (writes) in
> @@ -49,7 +46,6 @@
> private final ConcurrentMap<String, Long> commitsCountPerThreadGroup;
> private final ConcurrentMap<String, Long> commitsCountOtherThreads;
> private final ConcurrentMap<String, Long> commitsCountPerThreadGroupLastMinute;
> - private final Scheduler commitsTrackerScheduler = new Scheduler("CommitsTracker background tasks");
> CommitsTracker(String[] threadGroups, int otherWritersLimit, boolean collectStackTraces) {
> this.threadGroups = threadGroups;
> @@ -60,8 +56,6 @@
> .maximumWeightedCapacity(otherWritersLimit).build();
> this.queuedWritersMap = new ConcurrentHashMap<>();
> - commitsTrackerScheduler.scheduleWithFixedDelay("TarMK commits tracker stats resetter", 1, MINUTES,
> - this::resetStatistics);
> }
> public void trackQueuedCommitOf(Thread t) {
> @@ -112,7 +106,7 @@
> @Override
> public void close() {
> - commitsTrackerScheduler.close();
> +
> }
> {code}
> cc [~dulceanu]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)