[jira] [Commented] (OAK-7834) Add a tool to identify super-root nodes

2018-10-16 Thread JIRA 


[ 
https://issues.apache.org/jira/browse/OAK-7834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16651269#comment-16651269
 ] 

Michael Dürig commented on OAK-7834:


Very useful! I could successfully recover a journal of a big repository using 
this tool.

One thing that would be helpful would be to bring the output format closer to 
the one of the {{journal.log}}. This would save a lot of copy-pasting.

> Add a tool to identify super-root nodes
> ---
>
> Key: OAK-7834
> URL: https://issues.apache.org/jira/browse/OAK-7834
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: segment-tar
>Reporter: Francesco Mari
>Assignee: Francesco Mari
>Priority: Major
> Fix For: 1.10
>
> Attachments: OAK-7834-01.patch, OAK-7834-02.patch
>
>
> oak-segment-tar should have a tool that allows users to search for super-root 
> nodes.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (OAK-7837) oak-run check crashes with SNFE

2018-10-16 Thread JIRA 
Michael Dürig created OAK-7837:
--

 Summary: oak-run check crashes with SNFE
 Key: OAK-7837
 URL: https://issues.apache.org/jira/browse/OAK-7837
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: run, segment-tar
Reporter: Michael Dürig
Assignee: Michael Dürig


I experienced a crash of {{oak-run check}} with a {{SNFE}}:
{noformat}
org.apache.jackrabbit.oak.segment.SegmentNotFoundException: Segment 
48973c89-9e61-4757-a93d-384da83ec170 not found
at 
org.apache.jackrabbit.oak.segment.file.AbstractFileStore.readSegmentUncached(AbstractFileStore.java:281)
at 
org.apache.jackrabbit.oak.segment.file.ReadOnlyFileStore$1.call(ReadOnlyFileStore.java:124)
at 
org.apache.jackrabbit.oak.segment.file.ReadOnlyFileStore$1.call(ReadOnlyFileStore.java:121)
at 
org.apache.jackrabbit.oak.segment.SegmentCache$NonEmptyCache.lambda$getSegment$0(SegmentCache.java:163)
at 
com.google.common.cache.LocalCache$LocalManualCache$1.load(LocalCache.java:4724)
at 
com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3522)
at com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2315)
at 
com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2278)
at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2193)
at com.google.common.cache.LocalCache.get(LocalCache.java:3932)
at com.google.common.cache.LocalCache$LocalManualCache.get(LocalCache.java:4721)
at 
org.apache.jackrabbit.oak.segment.SegmentCache$NonEmptyCache.getSegment(SegmentCache.java:160)
at 
org.apache.jackrabbit.oak.segment.file.ReadOnlyFileStore.readSegment(ReadOnlyFileStore.java:121)
at org.apache.jackrabbit.oak.segment.SegmentId.getSegment(SegmentId.java:153)
at org.apache.jackrabbit.oak.segment.Record.getSegment(Record.java:70)
at org.apache.jackrabbit.oak.segment.MapRecord.getEntry(MapRecord.java:160)
at org.apache.jackrabbit.oak.segment.MapRecord.getEntry(MapRecord.java:172)
at 
org.apache.jackrabbit.oak.segment.SegmentNodeState.hasChildNode(SegmentNodeState.java:441)
at 
org.apache.jackrabbit.oak.segment.file.tooling.ConsistencyChecker$NodeWrapper.deriveTraversableNodeOnPath(ConsistencyChecker.java:498)
at 
org.apache.jackrabbit.oak.segment.file.tooling.ConsistencyChecker.checkPathAtRoot(ConsistencyChecker.java:383)
at 
org.apache.jackrabbit.oak.segment.file.tooling.ConsistencyChecker.checkPathsAtRoot(ConsistencyChecker.java:353)
at 
org.apache.jackrabbit.oak.segment.file.tooling.ConsistencyChecker.checkConsistency(ConsistencyChecker.java:200)
at org.apache.jackrabbit.oak.segment.tool.Check.run(Check.java:243)
at org.apache.jackrabbit.oak.run.CheckCommand.execute(CheckCommand.java:88)
at org.apache.jackrabbit.oak.run.Main.main(Main.java:49)
{noformat}

AFAICS the problem is the check of the path not being resilient against 
{{SNFE}}.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-7837) oak-run check crashes with SNFE

2018-10-16 Thread JIRA 


 [ 
https://issues.apache.org/jira/browse/OAK-7837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Dürig updated OAK-7837:
---
Attachment: OAK-7837.patch

> oak-run check crashes with SNFE
> ---
>
> Key: OAK-7837
> URL: https://issues.apache.org/jira/browse/OAK-7837
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: run, segment-tar
>Reporter: Michael Dürig
>Assignee: Michael Dürig
>Priority: Major
> Attachments: OAK-7837.patch
>
>
> I experienced a crash of {{oak-run check}} with a {{SNFE}}:
> {noformat}
> org.apache.jackrabbit.oak.segment.SegmentNotFoundException: Segment 
> 48973c89-9e61-4757-a93d-384da83ec170 not found
> at 
> org.apache.jackrabbit.oak.segment.file.AbstractFileStore.readSegmentUncached(AbstractFileStore.java:281)
> at 
> org.apache.jackrabbit.oak.segment.file.ReadOnlyFileStore$1.call(ReadOnlyFileStore.java:124)
> at 
> org.apache.jackrabbit.oak.segment.file.ReadOnlyFileStore$1.call(ReadOnlyFileStore.java:121)
> at 
> org.apache.jackrabbit.oak.segment.SegmentCache$NonEmptyCache.lambda$getSegment$0(SegmentCache.java:163)
> at 
> com.google.common.cache.LocalCache$LocalManualCache$1.load(LocalCache.java:4724)
> at 
> com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3522)
> at com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2315)
> at 
> com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2278)
> at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2193)
> at com.google.common.cache.LocalCache.get(LocalCache.java:3932)
> at 
> com.google.common.cache.LocalCache$LocalManualCache.get(LocalCache.java:4721)
> at 
> org.apache.jackrabbit.oak.segment.SegmentCache$NonEmptyCache.getSegment(SegmentCache.java:160)
> at 
> org.apache.jackrabbit.oak.segment.file.ReadOnlyFileStore.readSegment(ReadOnlyFileStore.java:121)
> at org.apache.jackrabbit.oak.segment.SegmentId.getSegment(SegmentId.java:153)
> at org.apache.jackrabbit.oak.segment.Record.getSegment(Record.java:70)
> at org.apache.jackrabbit.oak.segment.MapRecord.getEntry(MapRecord.java:160)
> at org.apache.jackrabbit.oak.segment.MapRecord.getEntry(MapRecord.java:172)
> at 
> org.apache.jackrabbit.oak.segment.SegmentNodeState.hasChildNode(SegmentNodeState.java:441)
> at 
> org.apache.jackrabbit.oak.segment.file.tooling.ConsistencyChecker$NodeWrapper.deriveTraversableNodeOnPath(ConsistencyChecker.java:498)
> at 
> org.apache.jackrabbit.oak.segment.file.tooling.ConsistencyChecker.checkPathAtRoot(ConsistencyChecker.java:383)
> at 
> org.apache.jackrabbit.oak.segment.file.tooling.ConsistencyChecker.checkPathsAtRoot(ConsistencyChecker.java:353)
> at 
> org.apache.jackrabbit.oak.segment.file.tooling.ConsistencyChecker.checkConsistency(ConsistencyChecker.java:200)
> at org.apache.jackrabbit.oak.segment.tool.Check.run(Check.java:243)
> at org.apache.jackrabbit.oak.run.CheckCommand.execute(CheckCommand.java:88)
> at org.apache.jackrabbit.oak.run.Main.main(Main.java:49)
> {noformat}
> AFAICS the problem is the check of the path not being resilient against 
> {{SNFE}}.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-7837) oak-run check crashes with SNFE

2018-10-16 Thread JIRA 


[ 
https://issues.apache.org/jira/browse/OAK-7837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16651291#comment-16651291
 ] 

Michael Dürig commented on OAK-7837:


Proposed patch:  [^OAK-7837.patch] 

[~dulceanu], could you have a look?

> oak-run check crashes with SNFE
> ---
>
> Key: OAK-7837
> URL: https://issues.apache.org/jira/browse/OAK-7837
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: run, segment-tar
>Reporter: Michael Dürig
>Assignee: Michael Dürig
>Priority: Major
> Attachments: OAK-7837.patch
>
>
> I experienced a crash of {{oak-run check}} with a {{SNFE}}:
> {noformat}
> org.apache.jackrabbit.oak.segment.SegmentNotFoundException: Segment 
> 48973c89-9e61-4757-a93d-384da83ec170 not found
> at 
> org.apache.jackrabbit.oak.segment.file.AbstractFileStore.readSegmentUncached(AbstractFileStore.java:281)
> at 
> org.apache.jackrabbit.oak.segment.file.ReadOnlyFileStore$1.call(ReadOnlyFileStore.java:124)
> at 
> org.apache.jackrabbit.oak.segment.file.ReadOnlyFileStore$1.call(ReadOnlyFileStore.java:121)
> at 
> org.apache.jackrabbit.oak.segment.SegmentCache$NonEmptyCache.lambda$getSegment$0(SegmentCache.java:163)
> at 
> com.google.common.cache.LocalCache$LocalManualCache$1.load(LocalCache.java:4724)
> at 
> com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3522)
> at com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2315)
> at 
> com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2278)
> at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2193)
> at com.google.common.cache.LocalCache.get(LocalCache.java:3932)
> at 
> com.google.common.cache.LocalCache$LocalManualCache.get(LocalCache.java:4721)
> at 
> org.apache.jackrabbit.oak.segment.SegmentCache$NonEmptyCache.getSegment(SegmentCache.java:160)
> at 
> org.apache.jackrabbit.oak.segment.file.ReadOnlyFileStore.readSegment(ReadOnlyFileStore.java:121)
> at org.apache.jackrabbit.oak.segment.SegmentId.getSegment(SegmentId.java:153)
> at org.apache.jackrabbit.oak.segment.Record.getSegment(Record.java:70)
> at org.apache.jackrabbit.oak.segment.MapRecord.getEntry(MapRecord.java:160)
> at org.apache.jackrabbit.oak.segment.MapRecord.getEntry(MapRecord.java:172)
> at 
> org.apache.jackrabbit.oak.segment.SegmentNodeState.hasChildNode(SegmentNodeState.java:441)
> at 
> org.apache.jackrabbit.oak.segment.file.tooling.ConsistencyChecker$NodeWrapper.deriveTraversableNodeOnPath(ConsistencyChecker.java:498)
> at 
> org.apache.jackrabbit.oak.segment.file.tooling.ConsistencyChecker.checkPathAtRoot(ConsistencyChecker.java:383)
> at 
> org.apache.jackrabbit.oak.segment.file.tooling.ConsistencyChecker.checkPathsAtRoot(ConsistencyChecker.java:353)
> at 
> org.apache.jackrabbit.oak.segment.file.tooling.ConsistencyChecker.checkConsistency(ConsistencyChecker.java:200)
> at org.apache.jackrabbit.oak.segment.tool.Check.run(Check.java:243)
> at org.apache.jackrabbit.oak.run.CheckCommand.execute(CheckCommand.java:88)
> at org.apache.jackrabbit.oak.run.Main.main(Main.java:49)
> {noformat}
> AFAICS the problem is the check of the path not being resilient against 
> {{SNFE}}.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-7837) oak-run check crashes with SNFE

2018-10-16 Thread JIRA 


 [ 
https://issues.apache.org/jira/browse/OAK-7837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Dürig updated OAK-7837:
---
Fix Version/s: 1.10

> oak-run check crashes with SNFE
> ---
>
> Key: OAK-7837
> URL: https://issues.apache.org/jira/browse/OAK-7837
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: run, segment-tar
>Reporter: Michael Dürig
>Assignee: Michael Dürig
>Priority: Major
> Fix For: 1.10
>
> Attachments: OAK-7837.patch
>
>
> I experienced a crash of {{oak-run check}} with a {{SNFE}}:
> {noformat}
> org.apache.jackrabbit.oak.segment.SegmentNotFoundException: Segment 
> 48973c89-9e61-4757-a93d-384da83ec170 not found
> at 
> org.apache.jackrabbit.oak.segment.file.AbstractFileStore.readSegmentUncached(AbstractFileStore.java:281)
> at 
> org.apache.jackrabbit.oak.segment.file.ReadOnlyFileStore$1.call(ReadOnlyFileStore.java:124)
> at 
> org.apache.jackrabbit.oak.segment.file.ReadOnlyFileStore$1.call(ReadOnlyFileStore.java:121)
> at 
> org.apache.jackrabbit.oak.segment.SegmentCache$NonEmptyCache.lambda$getSegment$0(SegmentCache.java:163)
> at 
> com.google.common.cache.LocalCache$LocalManualCache$1.load(LocalCache.java:4724)
> at 
> com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3522)
> at com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2315)
> at 
> com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2278)
> at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2193)
> at com.google.common.cache.LocalCache.get(LocalCache.java:3932)
> at 
> com.google.common.cache.LocalCache$LocalManualCache.get(LocalCache.java:4721)
> at 
> org.apache.jackrabbit.oak.segment.SegmentCache$NonEmptyCache.getSegment(SegmentCache.java:160)
> at 
> org.apache.jackrabbit.oak.segment.file.ReadOnlyFileStore.readSegment(ReadOnlyFileStore.java:121)
> at org.apache.jackrabbit.oak.segment.SegmentId.getSegment(SegmentId.java:153)
> at org.apache.jackrabbit.oak.segment.Record.getSegment(Record.java:70)
> at org.apache.jackrabbit.oak.segment.MapRecord.getEntry(MapRecord.java:160)
> at org.apache.jackrabbit.oak.segment.MapRecord.getEntry(MapRecord.java:172)
> at 
> org.apache.jackrabbit.oak.segment.SegmentNodeState.hasChildNode(SegmentNodeState.java:441)
> at 
> org.apache.jackrabbit.oak.segment.file.tooling.ConsistencyChecker$NodeWrapper.deriveTraversableNodeOnPath(ConsistencyChecker.java:498)
> at 
> org.apache.jackrabbit.oak.segment.file.tooling.ConsistencyChecker.checkPathAtRoot(ConsistencyChecker.java:383)
> at 
> org.apache.jackrabbit.oak.segment.file.tooling.ConsistencyChecker.checkPathsAtRoot(ConsistencyChecker.java:353)
> at 
> org.apache.jackrabbit.oak.segment.file.tooling.ConsistencyChecker.checkConsistency(ConsistencyChecker.java:200)
> at org.apache.jackrabbit.oak.segment.tool.Check.run(Check.java:243)
> at org.apache.jackrabbit.oak.run.CheckCommand.execute(CheckCommand.java:88)
> at org.apache.jackrabbit.oak.run.Main.main(Main.java:49)
> {noformat}
> AFAICS the problem is the check of the path not being resilient against 
> {{SNFE}}.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (OAK-7838) oak-run check crashes JVM

2018-10-16 Thread JIRA 
Michael Dürig created OAK-7838:
--

 Summary: 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
 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 commitsCountPerThreadGroup;
private final ConcurrentMap commitsCountOtherThreads;
private final ConcurrentMap 
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}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-7838) oak-run check crashes JVM

2018-10-16 Thread JIRA 


 [ 
https://issues.apache.org/jira/browse/OAK-7838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Dürig updated OAK-7838:
---
Description: 
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 commitsCountPerThreadGroup;
private final ConcurrentMap commitsCountOtherThreads;
private final ConcurrentMap 
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]

  was:
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 commitsCountPerThreadGroup;
private final ConcurrentMap commitsCountOtherThreads;
private final ConcurrentMap 
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}


> 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

[jira] [Created] (OAK-7839) Evaluate exporting of index corruption metrics with Sling Metrics / DropWizard

2018-10-16 Thread Tommaso Teofili (JIRA) 
Tommaso Teofili created OAK-7839:


 Summary: Evaluate exporting of index corruption metrics with Sling 
Metrics / DropWizard
 Key: OAK-7839
 URL: https://issues.apache.org/jira/browse/OAK-7839
 Project: Jackrabbit Oak
  Issue Type: Task
  Components: indexing
Reporter: Tommaso Teofili
Assignee: Tommaso Teofili


In order to integrate with more metrics tools , we can evaluate exposing some 
indexing related metrics as Sling Metrics / DropWizard metrics.

This taks is just for the sake of evaluation and possible integration points.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-7834) Add a tool to identify super-root nodes

2018-10-16 Thread Francesco Mari (JIRA) 


 [ 
https://issues.apache.org/jira/browse/OAK-7834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Francesco Mari updated OAK-7834:

Attachment: OAK-7834-03.patch

> Add a tool to identify super-root nodes
> ---
>
> Key: OAK-7834
> URL: https://issues.apache.org/jira/browse/OAK-7834
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: segment-tar
>Reporter: Francesco Mari
>Assignee: Francesco Mari
>Priority: Major
> Fix For: 1.10
>
> Attachments: OAK-7834-01.patch, OAK-7834-02.patch, OAK-7834-03.patch
>
>
> oak-segment-tar should have a tool that allows users to search for super-root 
> nodes.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-7837) oak-run check crashes with SNFE

2018-10-16 Thread Andrei Dulceanu (JIRA) 


[ 
https://issues.apache.org/jira/browse/OAK-7837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16651370#comment-16651370
 ] 

Andrei Dulceanu commented on OAK-7837:
--

[~mduerig], the patch looks good to me.

> oak-run check crashes with SNFE
> ---
>
> Key: OAK-7837
> URL: https://issues.apache.org/jira/browse/OAK-7837
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: run, segment-tar
>Reporter: Michael Dürig
>Assignee: Michael Dürig
>Priority: Major
> Fix For: 1.10
>
> Attachments: OAK-7837.patch
>
>
> I experienced a crash of {{oak-run check}} with a {{SNFE}}:
> {noformat}
> org.apache.jackrabbit.oak.segment.SegmentNotFoundException: Segment 
> 48973c89-9e61-4757-a93d-384da83ec170 not found
> at 
> org.apache.jackrabbit.oak.segment.file.AbstractFileStore.readSegmentUncached(AbstractFileStore.java:281)
> at 
> org.apache.jackrabbit.oak.segment.file.ReadOnlyFileStore$1.call(ReadOnlyFileStore.java:124)
> at 
> org.apache.jackrabbit.oak.segment.file.ReadOnlyFileStore$1.call(ReadOnlyFileStore.java:121)
> at 
> org.apache.jackrabbit.oak.segment.SegmentCache$NonEmptyCache.lambda$getSegment$0(SegmentCache.java:163)
> at 
> com.google.common.cache.LocalCache$LocalManualCache$1.load(LocalCache.java:4724)
> at 
> com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3522)
> at com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2315)
> at 
> com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2278)
> at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2193)
> at com.google.common.cache.LocalCache.get(LocalCache.java:3932)
> at 
> com.google.common.cache.LocalCache$LocalManualCache.get(LocalCache.java:4721)
> at 
> org.apache.jackrabbit.oak.segment.SegmentCache$NonEmptyCache.getSegment(SegmentCache.java:160)
> at 
> org.apache.jackrabbit.oak.segment.file.ReadOnlyFileStore.readSegment(ReadOnlyFileStore.java:121)
> at org.apache.jackrabbit.oak.segment.SegmentId.getSegment(SegmentId.java:153)
> at org.apache.jackrabbit.oak.segment.Record.getSegment(Record.java:70)
> at org.apache.jackrabbit.oak.segment.MapRecord.getEntry(MapRecord.java:160)
> at org.apache.jackrabbit.oak.segment.MapRecord.getEntry(MapRecord.java:172)
> at 
> org.apache.jackrabbit.oak.segment.SegmentNodeState.hasChildNode(SegmentNodeState.java:441)
> at 
> org.apache.jackrabbit.oak.segment.file.tooling.ConsistencyChecker$NodeWrapper.deriveTraversableNodeOnPath(ConsistencyChecker.java:498)
> at 
> org.apache.jackrabbit.oak.segment.file.tooling.ConsistencyChecker.checkPathAtRoot(ConsistencyChecker.java:383)
> at 
> org.apache.jackrabbit.oak.segment.file.tooling.ConsistencyChecker.checkPathsAtRoot(ConsistencyChecker.java:353)
> at 
> org.apache.jackrabbit.oak.segment.file.tooling.ConsistencyChecker.checkConsistency(ConsistencyChecker.java:200)
> at org.apache.jackrabbit.oak.segment.tool.Check.run(Check.java:243)
> at org.apache.jackrabbit.oak.run.CheckCommand.execute(CheckCommand.java:88)
> at org.apache.jackrabbit.oak.run.Main.main(Main.java:49)
> {noformat}
> AFAICS the problem is the check of the path not being resilient against 
> {{SNFE}}.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-7834) Add a tool to identify super-root nodes

2018-10-16 Thread Francesco Mari (JIRA) 


[ 
https://issues.apache.org/jira/browse/OAK-7834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16651371#comment-16651371
 ] 

Francesco Mari commented on OAK-7834:
-

The third version of the patch adds a {{--output}} option, abbreviated to 
{{-o}}, which can be used to specify a different output format. The option 
defaults to {{text}}, which is the original output of the tool, but it can be 
given the value {{journal}} to output the record IDs in the same format used by 
the journal. Printing the output with {{-o journal}} doesn't affect the 
ordering of the entries. It is still necessary to order them according to their 
timestamp. Invoking the command with {{-o journal}} looks like this:

{noformat}
$ java -jar oak-run.jar search path/to/store -v jcr:primaryType=cq:Page -o 
journal | head
Apache Jackrabbit Oak 1.10-SNAPSHOT
a1d77122-b5a3-4421-a982-a8d1ec0ae024:2548 root 1539333739004
a1d77122-b5a3-4421-a982-a8d1ec0ae024:2551 root 1539333739004
a1d77122-b5a3-4421-a982-a8d1ec0ae024:2554 root 1539333739004
a1d77122-b5a3-4421-a982-a8d1ec0ae024:2557 root 1539333739004
a1d77122-b5a3-4421-a982-a8d1ec0ae024:2590 root 1539333739004
a1d77122-b5a3-4421-a982-a8d1ec0ae024:2593 root 1539333739004
a1d77122-b5a3-4421-a982-a8d1ec0ae024:2596 root 1539333739004
a1d77122-b5a3-4421-a982-a8d1ec0ae024:2599 root 1539333739004
a1d77122-b5a3-4421-a982-a8d1ec0ae024:2630 root 1539333739004
{noformat}

[~mduerig], if there are no objections I'm going to commit the third iteration 
of the patch to trunk today.

> Add a tool to identify super-root nodes
> ---
>
> Key: OAK-7834
> URL: https://issues.apache.org/jira/browse/OAK-7834
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: segment-tar
>Reporter: Francesco Mari
>Assignee: Francesco Mari
>Priority: Major
> Fix For: 1.10
>
> Attachments: OAK-7834-01.patch, OAK-7834-02.patch, OAK-7834-03.patch
>
>
> oak-segment-tar should have a tool that allows users to search for super-root 
> nodes.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-7839) Evaluate exporting of index corruption metrics with Sling Metrics / DropWizard

2018-10-16 Thread Tommaso Teofili (JIRA) 


[ 
https://issues.apache.org/jira/browse/OAK-7839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16651391#comment-16651391
 ] 

Tommaso Teofili commented on OAK-7839:
--

I've just realised there's a dedicated package which depends on DW APIs already 
in _oak-core_ at 
[https://github.com/apache/jackrabbit-oak/tree/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/metric.]

So I assume that we will go with DW APIs directly, without introducing further 
dependencies.

> Evaluate exporting of index corruption metrics with Sling Metrics / DropWizard
> --
>
> Key: OAK-7839
> URL: https://issues.apache.org/jira/browse/OAK-7839
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: indexing
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
>Priority: Major
>
> In order to integrate with more metrics tools , we can evaluate exposing some 
> indexing related metrics as Sling Metrics / DropWizard metrics.
> This taks is just for the sake of evaluation and possible integration points.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-7834) Add a tool to identify super-root nodes

2018-10-16 Thread JIRA 


[ 
https://issues.apache.org/jira/browse/OAK-7834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16651421#comment-16651421
 ] 

Michael Dürig commented on OAK-7834:


Didn't look at the patch, but the output looks good. Trust the patch to be good 
as well. 

> Add a tool to identify super-root nodes
> ---
>
> Key: OAK-7834
> URL: https://issues.apache.org/jira/browse/OAK-7834
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: segment-tar
>Reporter: Francesco Mari
>Assignee: Francesco Mari
>Priority: Major
> Fix For: 1.10
>
> Attachments: OAK-7834-01.patch, OAK-7834-02.patch, OAK-7834-03.patch
>
>
> oak-segment-tar should have a tool that allows users to search for super-root 
> nodes.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (OAK-7840) Build Jackrabbit Oak #1730 failed

2018-10-16 Thread Hudson (JIRA) 
Hudson created OAK-7840:
---

 Summary: Build Jackrabbit Oak #1730 failed
 Key: OAK-7840
 URL: https://issues.apache.org/jira/browse/OAK-7840
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: continuous integration
Reporter: Hudson


No description is provided

The build Jackrabbit Oak #1730 has failed.
First failed run: [Jackrabbit Oak 
#1730|https://builds.apache.org/job/Jackrabbit%20Oak/1730/] [console 
log|https://builds.apache.org/job/Jackrabbit%20Oak/1730/console]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (OAK-7841) Off Heap Access causes OOME for OffRC

2018-10-16 Thread Andrei Dulceanu (JIRA) 
Andrei Dulceanu created OAK-7841:


 Summary: Off Heap Access causes OOME for OffRC
 Key: OAK-7841
 URL: https://issues.apache.org/jira/browse/OAK-7841
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: segment-tar
Reporter: Andrei Dulceanu
Assignee: Andrei Dulceanu


Running OffRC on a machine with 14GB of RAM with 8GB of heap, 4GB of segment 
cache and off heap access enabled, an OOME is thrown:

{noformat}
Caused by: java.lang.OutOfMemoryError: Direct buffer memory
at java.nio.Bits.reserveMemory(Bits.java:695)
at java.nio.DirectByteBuffer.(DirectByteBuffer.java:123)
at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:311)
at 
org.apache.jackrabbit.oak.segment.file.tar.FileAccess$Random.read(FileAccess.java:121)
at 
org.apache.jackrabbit.oak.segment.file.tar.SegmentTarReader.readSegment(SegmentTarReader.java:82)
at 
org.apache.jackrabbit.oak.segment.file.tar.TarReader.readEntry(TarReader.java:309)
at 
org.apache.jackrabbit.oak.segment.file.tar.TarFiles.readSegment(TarFiles.java:522)
at 
org.apache.jackrabbit.oak.segment.file.AbstractFileStore.readSegmentUncached(AbstractFileStore.java:279)
at 
org.apache.jackrabbit.oak.segment.file.FileStore.lambda$readSegment$9(FileStore.java:470)
at 
org.apache.jackrabbit.oak.segment.SegmentCache$NonEmptyCache.lambda$getSegment$0(SegmentCache.java:163)
at 
com.google.common.cache.LocalCache$LocalManualCache$1.load(LocalCache.java:4724)
at 
com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3522)
at com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2315)
at 
com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2278)
at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2193)
{noformat}

/cc [~mduerig]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (OAK-7842) solr: suppress problematics commons-fileupload dependency

2018-10-16 Thread Julian Reschke (JIRA) 
Julian Reschke created OAK-7842:
---

 Summary: solr: suppress problematics commons-fileupload dependency
 Key: OAK-7842
 URL: https://issues.apache.org/jira/browse/OAK-7842
 Project: Jackrabbit Oak
  Issue Type: Task
  Components: solr
Reporter: Julian Reschke
Assignee: Julian Reschke
 Fix For: 1.10






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-7842) solr: suppress problematic commons-fileupload dependency

2018-10-16 Thread Julian Reschke (JIRA) 


 [ 
https://issues.apache.org/jira/browse/OAK-7842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Reschke updated OAK-7842:

Summary: solr: suppress problematic commons-fileupload dependency  (was: 
solr: suppress problematics commons-fileupload dependency)

> solr: suppress problematic commons-fileupload dependency
> 
>
> Key: OAK-7842
> URL: https://issues.apache.org/jira/browse/OAK-7842
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: solr
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Trivial
> Fix For: 1.10, 1.9.10
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (OAK-7842) solr: suppress problematic commons-fileupload dependency

2018-10-16 Thread Julian Reschke (JIRA) 


 [ 
https://issues.apache.org/jira/browse/OAK-7842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Reschke resolved OAK-7842.
-
   Resolution: Fixed
Fix Version/s: 1.9.10

> solr: suppress problematic commons-fileupload dependency
> 
>
> Key: OAK-7842
> URL: https://issues.apache.org/jira/browse/OAK-7842
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: solr
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Trivial
> Fix For: 1.10, 1.9.10
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-7842) solr: suppress problematic commons-fileupload dependency

2018-10-16 Thread Julian Reschke (JIRA) 


[ 
https://issues.apache.org/jira/browse/OAK-7842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16651541#comment-16651541
 ] 

Julian Reschke commented on OAK-7842:
-

trunk: [r1843994|http://svn.apache.org/r1843994]

> solr: suppress problematic commons-fileupload dependency
> 
>
> Key: OAK-7842
> URL: https://issues.apache.org/jira/browse/OAK-7842
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: solr
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Trivial
>  Labels: candidate_oak_1_8
> Fix For: 1.10, 1.9.10
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-7842) solr: suppress problematic commons-fileupload dependency

2018-10-16 Thread Julian Reschke (JIRA) 


 [ 
https://issues.apache.org/jira/browse/OAK-7842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Reschke updated OAK-7842:

Labels: candidate_oak_1_8  (was: )

> solr: suppress problematic commons-fileupload dependency
> 
>
> Key: OAK-7842
> URL: https://issues.apache.org/jira/browse/OAK-7842
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: solr
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Trivial
>  Labels: candidate_oak_1_8
> Fix For: 1.10, 1.9.10
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (OAK-7834) Add a tool to identify super-root nodes

2018-10-16 Thread Francesco Mari (JIRA) 


 [ 
https://issues.apache.org/jira/browse/OAK-7834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Francesco Mari resolved OAK-7834.
-
   Resolution: Fixed
Fix Version/s: 1.9.10

Fixed at 1844005.

> Add a tool to identify super-root nodes
> ---
>
> Key: OAK-7834
> URL: https://issues.apache.org/jira/browse/OAK-7834
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: segment-tar
>Reporter: Francesco Mari
>Assignee: Francesco Mari
>Priority: Major
> Fix For: 1.10, 1.9.10
>
> Attachments: OAK-7834-01.patch, OAK-7834-02.patch, OAK-7834-03.patch
>
>
> oak-segment-tar should have a tool that allows users to search for super-root 
> nodes.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-7840) Build Jackrabbit Oak #1730 failed

2018-10-16 Thread Hudson (JIRA) 


[ 
https://issues.apache.org/jira/browse/OAK-7840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16651722#comment-16651722
 ] 

Hudson commented on OAK-7840:
-

Build is still failing.
Failed run: [Jackrabbit Oak 
#1731|https://builds.apache.org/job/Jackrabbit%20Oak/1731/] [console 
log|https://builds.apache.org/job/Jackrabbit%20Oak/1731/console]

> Build Jackrabbit Oak #1730 failed
> -
>
> Key: OAK-7840
> URL: https://issues.apache.org/jira/browse/OAK-7840
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: continuous integration
>Reporter: Hudson
>Priority: Major
>
> No description is provided
> The build Jackrabbit Oak #1730 has failed.
> First failed run: [Jackrabbit Oak 
> #1730|https://builds.apache.org/job/Jackrabbit%20Oak/1730/] [console 
> log|https://builds.apache.org/job/Jackrabbit%20Oak/1730/console]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-7024) java.security.acl deprecated in Java 10, marked for removal in Java 12

2018-10-16 Thread Julian Reschke (JIRA) 


 [ 
https://issues.apache.org/jira/browse/OAK-7024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Reschke updated OAK-7024:

Description: 
See  and 
.

Need to understand how this affects public Oak APIs, and what to do with them 
on Java 12 (which will be an LTS release we probably need to support with Oak 
1.10).


  was:
See  and 
.

Need to understand how this affects public Oak APIs, and what to do with them 
on Java 11 (which will be an LTS release we probably need to support with Oak 
1.10).



> java.security.acl deprecated in Java 10, marked for removal in Java 12
> --
>
> Key: OAK-7024
> URL: https://issues.apache.org/jira/browse/OAK-7024
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: security
>Reporter: Julian Reschke
>Assignee: Alex Deparvu
>Priority: Major
> Fix For: 1.9.0, 1.10
>
>
> See  and 
> .
> Need to understand how this affects public Oak APIs, and what to do with them 
> on Java 12 (which will be an LTS release we probably need to support with Oak 
> 1.10).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (OAK-7843) oak-upgrade doesn't correctly pass segment cache size to file store

2018-10-16 Thread Andrei Dulceanu (JIRA) 
Andrei Dulceanu created OAK-7843:


 Summary: oak-upgrade doesn't correctly pass segment cache size to 
file store
 Key: OAK-7843
 URL: https://issues.apache.org/jira/browse/OAK-7843
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: upgrade
Reporter: Andrei Dulceanu
Assignee: Andrei Dulceanu


When setting a segment cache size via the {{--cache SEGMENT_CACHE_SIZE}} 
option, {{oak-upgrade}} doesn't correctly pass it to the file store, although 
it correctly logs the value right after start. Below meaningful lines from the 
log, when trying to set a segment cache of 8GB:

{noformat}
[...]
16.10.2018 17:00:29.834 [main] *INFO*  
org.apache.jackrabbit.oak.upgrade.cli.parser.MigrationOptions - Cache size: 
8192 MB
[..]
16.10.2018 17:00:30.144 [main] *INFO*  
org.apache.jackrabbit.oak.segment.file.FileStore - Creating file store 
FileStoreBuilder{version=1.10-SNAPSHOT, directory=repository/segmentstore, 
blobStore=org.apache.jackrabbit.oak.upgrade.cli.blob.LoopbackBlobStore@33b37288,
 maxFileSize=256, segmentCacheSize=256, stringCacheSize=256, 
templateCacheSize=64, stringDeduplicationCacheSize=15000, 
templateDeduplicationCacheSize=3000, nodeDeduplicationCacheSize=1048576, 
memoryMapping=false, gcOptions=SegmentGCOptions{paused=false, 
estimationDisabled=false, gcSizeDeltaEstimation=1073741824, retryCount=5, 
forceTimeout=60, retainedGenerations=2, gcType=FULL}}
{noformat}

It can be observed that the segment cache size remained at 256MB (default).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-7834) Add a tool to identify super-root nodes

2018-10-16 Thread JIRA 


[ 
https://issues.apache.org/jira/browse/OAK-7834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16651836#comment-16651836
 ] 

Michael Dürig commented on OAK-7834:


[~frm], one thing I forgot: maybe use a more specific name for the run mode 
than {{search}}. Search is quite overloaded. May {{record-search}} or 
{{rsearch}} or similar. 

> Add a tool to identify super-root nodes
> ---
>
> Key: OAK-7834
> URL: https://issues.apache.org/jira/browse/OAK-7834
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: segment-tar
>Reporter: Francesco Mari
>Assignee: Francesco Mari
>Priority: Major
> Fix For: 1.10, 1.9.10
>
> Attachments: OAK-7834-01.patch, OAK-7834-02.patch, OAK-7834-03.patch
>
>
> oak-segment-tar should have a tool that allows users to search for super-root 
> nodes.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Reopened] (OAK-7834) Add a tool to identify super-root nodes

2018-10-16 Thread Francesco Mari (JIRA) 


 [ 
https://issues.apache.org/jira/browse/OAK-7834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Francesco Mari reopened OAK-7834:
-

[~mduerig], you are right. I would go for {{node-search}}, since this is 
exactly what the command does. Naming would be a lesser problem if OAK-5437 had 
been taken care of.

> Add a tool to identify super-root nodes
> ---
>
> Key: OAK-7834
> URL: https://issues.apache.org/jira/browse/OAK-7834
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: segment-tar
>Reporter: Francesco Mari
>Assignee: Francesco Mari
>Priority: Major
> Fix For: 1.10, 1.9.10
>
> Attachments: OAK-7834-01.patch, OAK-7834-02.patch, OAK-7834-03.patch
>
>
> oak-segment-tar should have a tool that allows users to search for super-root 
> nodes.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-7834) Add a tool to identify super-root nodes

2018-10-16 Thread JIRA 


[ 
https://issues.apache.org/jira/browse/OAK-7834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16651857#comment-16651857
 ] 

Michael Dürig commented on OAK-7834:


bq.  node-search
+1

> Add a tool to identify super-root nodes
> ---
>
> Key: OAK-7834
> URL: https://issues.apache.org/jira/browse/OAK-7834
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: segment-tar
>Reporter: Francesco Mari
>Assignee: Francesco Mari
>Priority: Major
> Fix For: 1.10, 1.9.10
>
> Attachments: OAK-7834-01.patch, OAK-7834-02.patch, OAK-7834-03.patch
>
>
> oak-segment-tar should have a tool that allows users to search for super-root 
> nodes.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-7834) Add a tool to identify super-root nodes

2018-10-16 Thread Andrei Dulceanu (JIRA) 


[ 
https://issues.apache.org/jira/browse/OAK-7834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16651917#comment-16651917
 ] 

Andrei Dulceanu commented on OAK-7834:
--

[~frm], the patch LGTM.

> Add a tool to identify super-root nodes
> ---
>
> Key: OAK-7834
> URL: https://issues.apache.org/jira/browse/OAK-7834
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: segment-tar
>Reporter: Francesco Mari
>Assignee: Francesco Mari
>Priority: Major
> Fix For: 1.10, 1.9.10
>
> Attachments: OAK-7834-01.patch, OAK-7834-02.patch, OAK-7834-03.patch
>
>
> oak-segment-tar should have a tool that allows users to search for super-root 
> nodes.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-7840) Build Jackrabbit Oak #1730 failed

2018-10-16 Thread Hudson (JIRA) 


[ 
https://issues.apache.org/jira/browse/OAK-7840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16651960#comment-16651960
 ] 

Hudson commented on OAK-7840:
-

Previously failing build now is OK.
 Passed run: [Jackrabbit Oak 
#1732|https://builds.apache.org/job/Jackrabbit%20Oak/1732/] [console 
log|https://builds.apache.org/job/Jackrabbit%20Oak/1732/console]

> Build Jackrabbit Oak #1730 failed
> -
>
> Key: OAK-7840
> URL: https://issues.apache.org/jira/browse/OAK-7840
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: continuous integration
>Reporter: Hudson
>Priority: Major
>
> No description is provided
> The build Jackrabbit Oak #1730 has failed.
> First failed run: [Jackrabbit Oak 
> #1730|https://builds.apache.org/job/Jackrabbit%20Oak/1730/] [console 
> log|https://builds.apache.org/job/Jackrabbit%20Oak/1730/console]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (OAK-7843) oak-upgrade doesn't correctly pass segment cache size to file store

2018-10-16 Thread Andrei Dulceanu (JIRA) 


[ 
https://issues.apache.org/jira/browse/OAK-7843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16652006#comment-16652006
 ] 

Andrei Dulceanu edited comment on OAK-7843 at 10/16/18 4:07 PM:


[~tomek.rekawek], my understanding is that the segment cache size needs to be 
set only on the source repository, as that is the one doing all the reading, 
right? Could you take a look at  [^OAK-7843.patch] , please?

/cc [~mduerig]


was (Author: dulceanu):
[~tomek.rekawek], my understanding is that the segment cache size needs to be 
set only on the source repository, as that is the one doing all the reading, 
right? Could you take a look at the attached patch, please?

/cc [~mduerig] [^OAK-7843.patch] 

> oak-upgrade doesn't correctly pass segment cache size to file store
> ---
>
> Key: OAK-7843
> URL: https://issues.apache.org/jira/browse/OAK-7843
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: upgrade
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Minor
> Attachments: OAK-7843.patch
>
>
> When setting a segment cache size via the {{--cache SEGMENT_CACHE_SIZE}} 
> option, {{oak-upgrade}} doesn't correctly pass it to the file store, although 
> it correctly logs the value right after start. Below meaningful lines from 
> the log, when trying to set a segment cache of 8GB:
> {noformat}
> [...]
> 16.10.2018 17:00:29.834 [main] *INFO*  
> org.apache.jackrabbit.oak.upgrade.cli.parser.MigrationOptions - Cache size: 
> 8192 MB
> [..]
> 16.10.2018 17:00:30.144 [main] *INFO*  
> org.apache.jackrabbit.oak.segment.file.FileStore - Creating file store 
> FileStoreBuilder{version=1.10-SNAPSHOT, directory=repository/segmentstore, 
> blobStore=org.apache.jackrabbit.oak.upgrade.cli.blob.LoopbackBlobStore@33b37288,
>  maxFileSize=256, segmentCacheSize=256, stringCacheSize=256, 
> templateCacheSize=64, stringDeduplicationCacheSize=15000, 
> templateDeduplicationCacheSize=3000, nodeDeduplicationCacheSize=1048576, 
> memoryMapping=false, gcOptions=SegmentGCOptions{paused=false, 
> estimationDisabled=false, gcSizeDeltaEstimation=1073741824, retryCount=5, 
> forceTimeout=60, retainedGenerations=2, gcType=FULL}}
> {noformat}
> It can be observed that the segment cache size remained at 256MB (default).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-7843) oak-upgrade doesn't correctly pass segment cache size to file store

2018-10-16 Thread Andrei Dulceanu (JIRA) 


 [ 
https://issues.apache.org/jira/browse/OAK-7843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-7843:
-
Attachment: OAK-7843.patch

> oak-upgrade doesn't correctly pass segment cache size to file store
> ---
>
> Key: OAK-7843
> URL: https://issues.apache.org/jira/browse/OAK-7843
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: upgrade
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Minor
> Attachments: OAK-7843.patch
>
>
> When setting a segment cache size via the {{--cache SEGMENT_CACHE_SIZE}} 
> option, {{oak-upgrade}} doesn't correctly pass it to the file store, although 
> it correctly logs the value right after start. Below meaningful lines from 
> the log, when trying to set a segment cache of 8GB:
> {noformat}
> [...]
> 16.10.2018 17:00:29.834 [main] *INFO*  
> org.apache.jackrabbit.oak.upgrade.cli.parser.MigrationOptions - Cache size: 
> 8192 MB
> [..]
> 16.10.2018 17:00:30.144 [main] *INFO*  
> org.apache.jackrabbit.oak.segment.file.FileStore - Creating file store 
> FileStoreBuilder{version=1.10-SNAPSHOT, directory=repository/segmentstore, 
> blobStore=org.apache.jackrabbit.oak.upgrade.cli.blob.LoopbackBlobStore@33b37288,
>  maxFileSize=256, segmentCacheSize=256, stringCacheSize=256, 
> templateCacheSize=64, stringDeduplicationCacheSize=15000, 
> templateDeduplicationCacheSize=3000, nodeDeduplicationCacheSize=1048576, 
> memoryMapping=false, gcOptions=SegmentGCOptions{paused=false, 
> estimationDisabled=false, gcSizeDeltaEstimation=1073741824, retryCount=5, 
> forceTimeout=60, retainedGenerations=2, gcType=FULL}}
> {noformat}
> It can be observed that the segment cache size remained at 256MB (default).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-7843) oak-upgrade doesn't correctly pass segment cache size to file store

2018-10-16 Thread Andrei Dulceanu (JIRA) 


[ 
https://issues.apache.org/jira/browse/OAK-7843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16652006#comment-16652006
 ] 

Andrei Dulceanu commented on OAK-7843:
--

[~tomek.rekawek], my understanding is that the segment cache size needs to be 
set only on the source repository, as that is the one doing all the reading, 
right? Could you take a look at the attached patch, please?

/cc [~mduerig] [^OAK-7843.patch] 

> oak-upgrade doesn't correctly pass segment cache size to file store
> ---
>
> Key: OAK-7843
> URL: https://issues.apache.org/jira/browse/OAK-7843
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: upgrade
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Minor
> Attachments: OAK-7843.patch
>
>
> When setting a segment cache size via the {{--cache SEGMENT_CACHE_SIZE}} 
> option, {{oak-upgrade}} doesn't correctly pass it to the file store, although 
> it correctly logs the value right after start. Below meaningful lines from 
> the log, when trying to set a segment cache of 8GB:
> {noformat}
> [...]
> 16.10.2018 17:00:29.834 [main] *INFO*  
> org.apache.jackrabbit.oak.upgrade.cli.parser.MigrationOptions - Cache size: 
> 8192 MB
> [..]
> 16.10.2018 17:00:30.144 [main] *INFO*  
> org.apache.jackrabbit.oak.segment.file.FileStore - Creating file store 
> FileStoreBuilder{version=1.10-SNAPSHOT, directory=repository/segmentstore, 
> blobStore=org.apache.jackrabbit.oak.upgrade.cli.blob.LoopbackBlobStore@33b37288,
>  maxFileSize=256, segmentCacheSize=256, stringCacheSize=256, 
> templateCacheSize=64, stringDeduplicationCacheSize=15000, 
> templateDeduplicationCacheSize=3000, nodeDeduplicationCacheSize=1048576, 
> memoryMapping=false, gcOptions=SegmentGCOptions{paused=false, 
> estimationDisabled=false, gcSizeDeltaEstimation=1073741824, retryCount=5, 
> forceTimeout=60, retainedGenerations=2, gcType=FULL}}
> {noformat}
> It can be observed that the segment cache size remained at 256MB (default).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)