[jira] [Commented] (OAK-11244) Migrate Groovy code to Java
[ https://issues.apache.org/jira/browse/OAK-11244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17894812#comment-17894812 ] Marcel Reutegger commented on OAK-11244: Sounds reasonable. Can you list the Groovy files that need migration? > Migrate Groovy code to Java > --- > > Key: OAK-11244 > URL: https://issues.apache.org/jira/browse/OAK-11244 > Project: Jackrabbit Oak > Issue Type: Task >Reporter: Julian Reschke >Priority: Major > > We have a fest classes written in Groovy. > This poses problems when > - people not fluent in Groovy need to make changes or debug the code > - updating Java versions > There are only a few, we should just convert them to proper Java code. > [~stefanegli] [~mreutegg] [~angela] wdyt? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-11204) Incorrect order with more than 2^16 segments in remote archive
[ https://issues.apache.org/jira/browse/OAK-11204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved OAK-11204. Fix Version/s: 1.72.0 Resolution: Fixed PR looks good and I merged it. Thanks for the contribution. > Incorrect order with more than 2^16 segments in remote archive > -- > > Key: OAK-11204 > URL: https://issues.apache.org/jira/browse/OAK-11204 > Project: Jackrabbit Oak > Issue Type: Bug >Reporter: Lucas Weitzendorf >Assignee: Marcel Reutegger >Priority: Minor > Fix For: 1.72.0 > > > Segments in a remote archive are in incorrect order when there are more than > 65'536 segments. RemoteUtilities.getSegmentFileName() assumes four hex digits > are sufficient. > [https://github.com/apache/jackrabbit-oak/blob/8e72b238f4933a5bc6c0002ff3e15f9bbad6b3a0/oak-segment-remote/src/main/java/org/apache/jackrabbit/oak/segment/remote/RemoteUtilities.java#L43] > But after 64k segments the method simply adds another hex digit. We then see > file names generated like this: > ... > fffe. > . > 1. > 10001. > ... > Later when listing segments, they will appear in the following sequence: > ... > 0fffe. > 0. > 1000. > 10001. > 10002. > ... > Retrieving the UUID from such a file name will also stop working. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OAK-11204) Incorrect order with more than 2^16 segments in remote archive
[ https://issues.apache.org/jira/browse/OAK-11204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-11204: --- Summary: Incorrect order with more than 2^16 segments in remote archive (was: Incorrect order with more than 2^16 segments in remote tar file) > Incorrect order with more than 2^16 segments in remote archive > -- > > Key: OAK-11204 > URL: https://issues.apache.org/jira/browse/OAK-11204 > Project: Jackrabbit Oak > Issue Type: Bug >Reporter: Lucas Weitzendorf >Assignee: Marcel Reutegger >Priority: Minor > > Segments in a remote archive are in incorrect order when there are more than > 65'536 segments. RemoteUtilities.getSegmentFileName() assumes four hex digits > are sufficient. > [https://github.com/apache/jackrabbit-oak/blob/8e72b238f4933a5bc6c0002ff3e15f9bbad6b3a0/oak-segment-remote/src/main/java/org/apache/jackrabbit/oak/segment/remote/RemoteUtilities.java#L43] > But after 64k segments the method simply adds another hex digit. We then see > file names generated like this: > ... > fffe. > . > 1. > 10001. > ... > Later when listing segments, they will appear in the following sequence: > ... > 0fffe. > 0. > 1000. > 10001. > 10002. > ... > Retrieving the UUID from such a file name will also stop working. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OAK-11204) Incorrect order with more than 2^16 segments in remote tar file
[ https://issues.apache.org/jira/browse/OAK-11204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-11204: --- Description: Segments in a remote archive are in incorrect order when there are more than 65'536 segments. RemoteUtilities.getSegmentFileName() assumes four hex digits are sufficient. [https://github.com/apache/jackrabbit-oak/blob/8e72b238f4933a5bc6c0002ff3e15f9bbad6b3a0/oak-segment-remote/src/main/java/org/apache/jackrabbit/oak/segment/remote/RemoteUtilities.java#L43] But after 64k segments the method simply adds another hex digit. We then see file names generated like this: ... fffe. . 1. 10001. ... Later when listing segments, they will appear in the following sequence: ... 0fffe. 0. 1000. 10001. 10002. ... Retrieving the UUID from such a file name will also stop working. was: Segments in a tar are in incorrect order when there are more than 65'536 segments. RemoteUtilities.getSegmentFileName() assumes four hex digits are sufficient. [https://github.com/apache/jackrabbit-oak/blob/8e72b238f4933a5bc6c0002ff3e15f9bbad6b3a0/oak-segment-remote/src/main/java/org/apache/jackrabbit/oak/segment/remote/RemoteUtilities.java#L43] But after 64k segments the method simply adds another hex digit. We then see file names generated like this: ... fffe. . 1. 10001. ... Later when listing segments, they will appear in the following sequence: ... 0fffe. 0. 1000. 10001. 10002. ... Retrieving the UUID from such a file name will also stop working. > Incorrect order with more than 2^16 segments in remote tar file > --- > > Key: OAK-11204 > URL: https://issues.apache.org/jira/browse/OAK-11204 > Project: Jackrabbit Oak > Issue Type: Bug >Reporter: Lucas Weitzendorf >Assignee: Marcel Reutegger >Priority: Minor > > Segments in a remote archive are in incorrect order when there are more than > 65'536 segments. RemoteUtilities.getSegmentFileName() assumes four hex digits > are sufficient. > [https://github.com/apache/jackrabbit-oak/blob/8e72b238f4933a5bc6c0002ff3e15f9bbad6b3a0/oak-segment-remote/src/main/java/org/apache/jackrabbit/oak/segment/remote/RemoteUtilities.java#L43] > But after 64k segments the method simply adds another hex digit. We then see > file names generated like this: > ... > fffe. > . > 1. > 10001. > ... > Later when listing segments, they will appear in the following sequence: > ... > 0fffe. > 0. > 1000. > 10001. > 10002. > ... > Retrieving the UUID from such a file name will also stop working. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (OAK-11204) Incorrect order with more than 2^16 segments in remote tar file
[ https://issues.apache.org/jira/browse/OAK-11204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger reassigned OAK-11204: -- Assignee: Marcel Reutegger > Incorrect order with more than 2^16 segments in remote tar file > --- > > Key: OAK-11204 > URL: https://issues.apache.org/jira/browse/OAK-11204 > Project: Jackrabbit Oak > Issue Type: Bug >Reporter: Lucas Weitzendorf >Assignee: Marcel Reutegger >Priority: Minor > > Segments in a tar are in incorrect order when there are more than 65'536 > segments. RemoteUtilities.getSegmentFileName() assumes four hex digits are > sufficient. > [https://github.com/apache/jackrabbit-oak/blob/8e72b238f4933a5bc6c0002ff3e15f9bbad6b3a0/oak-segment-remote/src/main/java/org/apache/jackrabbit/oak/segment/remote/RemoteUtilities.java#L43] > But after 64k segments the method simply adds another hex digit. We then see > file names generated like this: > ... > fffe. > . > 1. > 10001. > ... > Later when listing segments, they will appear in the following sequence: > ... > 0fffe. > 0. > 1000. > 10001. > 10002. > ... > Retrieving the UUID from such a file name will also stop working. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-11134) Remove SegmentReader from Segment
[ https://issues.apache.org/jira/browse/OAK-11134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved OAK-11134. Fix Version/s: 1.70.0 Resolution: Fixed Merged the pull request. > Remove SegmentReader from Segment > - > > Key: OAK-11134 > URL: https://issues.apache.org/jira/browse/OAK-11134 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: segment-tar >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Fix For: 1.70.0 > > > The Segment class currently has a reference to a SegmentReader, which is used > in methods Segment.readTemplate() and Segment.readProps(). This requires > passing a SegmentReader through various other classes. The two mentioned > methods on Segment should be moved to CachingSegmentReader where the only > usage of readTemplate() happens. With this, the code can be simplified and > passing around a SegmentReader can be reduced. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OAK-11134) Remove SegmentReader from Segment
[ https://issues.apache.org/jira/browse/OAK-11134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-11134: --- Description: The Segment class currently has a reference to a SegmentReader, which is used in methods Segment.readTemplate() and Segment.readProps(). This requires passing a SegmentReader through various other classes. The two mentioned methods on Segment should be moved to CachingSegmentReader where the only usage of readTemplate() happens. With this, the code can be simplified and passing around a SegmentReader can be reduced. (was: The Segment class currently has a reference to a SegmentReader, which is used in methods Segment.readTemplate() and Segment.readProps(). This requires passing a SegmentReader through various other classes. The two mentioned methods on Segment should be moved to SegmentReader where the only usage of readTemplate() happens. With this, the code can be simplified and passing around a SegmentReader can be reduced.) > Remove SegmentReader from Segment > - > > Key: OAK-11134 > URL: https://issues.apache.org/jira/browse/OAK-11134 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: segment-tar >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > > The Segment class currently has a reference to a SegmentReader, which is used > in methods Segment.readTemplate() and Segment.readProps(). This requires > passing a SegmentReader through various other classes. The two mentioned > methods on Segment should be moved to CachingSegmentReader where the only > usage of readTemplate() happens. With this, the code can be simplified and > passing around a SegmentReader can be reduced. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-11134) Remove SegmentReader from Segment
Marcel Reutegger created OAK-11134: -- Summary: Remove SegmentReader from Segment Key: OAK-11134 URL: https://issues.apache.org/jira/browse/OAK-11134 Project: Jackrabbit Oak Issue Type: Improvement Components: segment-tar Reporter: Marcel Reutegger Assignee: Marcel Reutegger The Segment class currently has a reference to a SegmentReader, which is used in methods Segment.readTemplate() and Segment.readProps(). This requires passing a SegmentReader through various other classes. The two mentioned methods on Segment should be moved to SegmentReader where the only usage of readTemplate() happens. With this, the code can be simplified and passing around a SegmentReader can be reduced. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-11094) Allow the creation of Segment instances with a provided SegmentData instance
[ https://issues.apache.org/jira/browse/OAK-11094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved OAK-11094. Fix Version/s: 1.70.0 Resolution: Fixed PR looks good and I merged it. Thanks for the contribution. > Allow the creation of Segment instances with a provided SegmentData instance > > > Key: OAK-11094 > URL: https://issues.apache.org/jira/browse/OAK-11094 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: segment-tar >Affects Versions: 1.68.0 >Reporter: Nicolas Ettlin >Priority: Minor > Fix For: 1.70.0 > > > All currently existing constructors of Segment instantiate a SegmentData > instance from the provided data buffer (either byte[] or > org.apache.jackrabbit.oak.commons.Buffer). > In some cases where we would like to use a custom implementation of > SegmentData, it could be helpful to have a constructor that takes a > SegmentData instance instead. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-11090) Move the code that creates instances of RecordNumbers/SegmentReferences from SegmentData out of Segment
[ https://issues.apache.org/jira/browse/OAK-11090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved OAK-11090. Fix Version/s: 1.70.0 Resolution: Fixed PR looks good and I merged it. Thanks for the contribution. > Move the code that creates instances of RecordNumbers/SegmentReferences from > SegmentData out of Segment > --- > > Key: OAK-11090 > URL: https://issues.apache.org/jira/browse/OAK-11090 > Project: Jackrabbit Oak > Issue Type: Improvement >Reporter: Nicolas Ettlin >Priority: Minor > Fix For: 1.70.0 > > > When initializing a Segment instance, we create > RecordNumbers/SegmentReferences instances with the data contained in > SegmentData. This operation is currently done from two private methods, > Segment#readRecordNumberOffsets and Segment#readReferencedSegments. > By moving this code somewhere else (e.g. in static methods of > RecordNumbers/SegmentReferences), it would make it easier to reuse it and add > unit tests for these methods. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-11092) Make the constructors of RecordIdData/StringData public
[ https://issues.apache.org/jira/browse/OAK-11092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved OAK-11092. Fix Version/s: 1.70.0 Resolution: Fixed PR looks good to me and I merged it. Thanks for your contribution. > Make the constructors of RecordIdData/StringData public > --- > > Key: OAK-11092 > URL: https://issues.apache.org/jira/browse/OAK-11092 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: segment-tar >Affects Versions: 1.68.0 >Reporter: Nicolas Ettlin >Priority: Minor > Fix For: 1.70.0 > > > Currently, SegmentData is a public interface but it is not possible for code > in another package to implement it properly. Indeed, its readString and > readRecordId methods return instances of StringData/RecordIdData, which lack > public constructors. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-11091) Make Segment#readByte/readBytes public
[ https://issues.apache.org/jira/browse/OAK-11091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved OAK-11091. Fix Version/s: 1.70.0 Resolution: Fixed PR looks good and I merged it. Thanks for your contribution. > Make Segment#readByte/readBytes public > -- > > Key: OAK-11091 > URL: https://issues.apache.org/jira/browse/OAK-11091 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: segment-tar >Affects Versions: 1.68.0 >Reporter: Nicolas Ettlin >Priority: Minor > Fix For: 1.70.0 > > > These methods are currently package-private. Since they can be helpful when > writing unit tests that depend on the Segment class, I’m proposing to make > them public instead. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-11088) Create default implementations of readLength/readString/readRecordId in SegmentData
[ https://issues.apache.org/jira/browse/OAK-11088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved OAK-11088. Fix Version/s: 1.70.0 Resolution: Fixed PR looks good and I merged it. Thanks for the contribution. > Create default implementations of readLength/readString/readRecordId in > SegmentData > --- > > Key: OAK-11088 > URL: https://issues.apache.org/jira/browse/OAK-11088 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: segment-tar >Affects Versions: 1.68.0 >Reporter: Nicolas Ettlin >Priority: Minor > Fix For: 1.70.0 > > > Currently, the readLength/readString/readRecordId methods of SegmentData are > implemented in SegmentDataV12, while they only depend on other methods of > SegmentData (e.g. readInt). > Moving the existing implementations so that they become default methods of > SegmentData can be helpful when creating new implementations of SegmentData. > This change is also backwards-compatible -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-11085) Constant MAX_SEGMENT_SIZE is duplicated in Segment/SegmentDataUtils
[ https://issues.apache.org/jira/browse/OAK-11085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved OAK-11085. Fix Version/s: 1.70.0 Resolution: Fixed As mentioned in PR #1702, Nicolas already opened https://github.com/apache/jackrabbit-oak/pull/1692 The changes look good and I merged the PR. Thank you for the contribution. > Constant MAX_SEGMENT_SIZE is duplicated in Segment/SegmentDataUtils > --- > > Key: OAK-11085 > URL: https://issues.apache.org/jira/browse/OAK-11085 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: segment-tar >Affects Versions: 1.68.0 >Reporter: Nicolas Ettlin >Priority: Trivial > Fix For: 1.70.0 > > > The constant MAX_SEGMENT_SIZE is defined in both Segment and SegmentDataUtils > with the same value. It should only be defined once instead. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OAK-11075) Add a Buffer#getShort() API
[
https://issues.apache.org/jira/browse/OAK-11075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger updated OAK-11075:
---
Issue Type: Improvement (was: Bug)
> Add a Buffer#getShort() API
> ---
>
> Key: OAK-11075
> URL: https://issues.apache.org/jira/browse/OAK-11075
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: commons
>Affects Versions: 1.68.0
>Reporter: Nicolas Ettlin
>Assignee: Marcel Reutegger
>Priority: Minor
>
> {{org.apache.jackrabbit.oak.commons.Buffer}} misses a method to getting a
> short from the current position of the buffer, similarly to other APIs
> already provided such as {{{}Buffer#getLong(){}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (OAK-11075) Add a Buffer#getShort() API
[
https://issues.apache.org/jira/browse/OAK-11075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger reassigned OAK-11075:
--
Assignee: Marcel Reutegger
> Add a Buffer#getShort() API
> ---
>
> Key: OAK-11075
> URL: https://issues.apache.org/jira/browse/OAK-11075
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: commons
>Affects Versions: 1.68.0
>Reporter: Nicolas Ettlin
>Assignee: Marcel Reutegger
>Priority: Minor
>
> {{org.apache.jackrabbit.oak.commons.Buffer}} misses a method to getting a
> short from the current position of the buffer, similarly to other APIs
> already provided such as {{{}Buffer#getLong(){}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (OAK-11060) Avoid String allocation in ListRecord constructor
[ https://issues.apache.org/jira/browse/OAK-11060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved OAK-11060. Fix Version/s: 1.70.0 Resolution: Fixed Merged the PR. > Avoid String allocation in ListRecord constructor > - > > Key: OAK-11060 > URL: https://issues.apache.org/jira/browse/OAK-11060 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: segment-tar >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Fix For: 1.70.0 > > > There are two size argument checks in the ListRecord constructor. Both > allocate a String as a potential error message. > These checks should use another checkArgument() method with an error message > template to avoid String allocation. > A micro benchmark shows cost of SegmentNodeState.getProperties() reduced by > 30% when String allocation is avoided in the constructor. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-11077) Resource leak in tests
[ https://issues.apache.org/jira/browse/OAK-11077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved OAK-11077. Fix Version/s: 1.70.0 Resolution: Fixed Merged the PR. > Resource leak in tests > -- > > Key: OAK-11077 > URL: https://issues.apache.org/jira/browse/OAK-11077 > Project: Jackrabbit Oak > Issue Type: Bug > Components: jcr >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Fix For: 1.70.0 > > > Some tests in oak-jcr leak memory. RefreshOnGCTest and tests using > SegmentMemoryNodeStoreFixture create FileStore instances and do not close > them at the end. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-11077) Resource leak in tests
[ https://issues.apache.org/jira/browse/OAK-11077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878871#comment-17878871 ] Marcel Reutegger commented on OAK-11077: Proposed changes in https://github.com/apache/jackrabbit-oak/pull/1682 > Resource leak in tests > -- > > Key: OAK-11077 > URL: https://issues.apache.org/jira/browse/OAK-11077 > Project: Jackrabbit Oak > Issue Type: Bug > Components: jcr >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > > Some tests in oak-jcr leak memory. RefreshOnGCTest and tests using > SegmentMemoryNodeStoreFixture create FileStore instances and do not close > them at the end. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-11077) Resource leak in tests
Marcel Reutegger created OAK-11077: -- Summary: Resource leak in tests Key: OAK-11077 URL: https://issues.apache.org/jira/browse/OAK-11077 Project: Jackrabbit Oak Issue Type: Bug Components: jcr Reporter: Marcel Reutegger Assignee: Marcel Reutegger Some tests in oak-jcr leak memory. RefreshOnGCTest and tests using SegmentMemoryNodeStoreFixture create FileStore instances and do not close them at the end. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-11060) Avoid String allocation in ListRecord constructor
[ https://issues.apache.org/jira/browse/OAK-11060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17876266#comment-17876266 ] Marcel Reutegger commented on OAK-11060: Created PR https://github.com/apache/jackrabbit-oak/pull/1668 > Avoid String allocation in ListRecord constructor > - > > Key: OAK-11060 > URL: https://issues.apache.org/jira/browse/OAK-11060 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: segment-tar >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > > There are two size argument checks in the ListRecord constructor. Both > allocate a String as a potential error message. > These checks should use another checkArgument() method with an error message > template to avoid String allocation. > A micro benchmark shows cost of SegmentNodeState.getProperties() reduced by > 30% when String allocation is avoided in the constructor. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-11060) Avoid String allocation in ListRecord constructor
Marcel Reutegger created OAK-11060: -- Summary: Avoid String allocation in ListRecord constructor Key: OAK-11060 URL: https://issues.apache.org/jira/browse/OAK-11060 Project: Jackrabbit Oak Issue Type: Improvement Components: segment-tar Reporter: Marcel Reutegger Assignee: Marcel Reutegger There are two size argument checks in the ListRecord constructor. Both allocate a String as a potential error message. These checks should use another checkArgument() method with an error message template to avoid String allocation. A micro benchmark shows cost of SegmentNodeState.getProperties() reduced by 30% when String allocation is avoided in the constructor. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-9796) oak-segment-remote and oak-segment-aws Redis tests fail with ARM processor (Apple M1)
[ https://issues.apache.org/jira/browse/OAK-9796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved OAK-9796. --- Fix Version/s: 1.60.0 (was: 1.42.0) (was: 1.22.11) Resolution: Fixed Both PRs are now merged. Resolving this issue. > oak-segment-remote and oak-segment-aws Redis tests fail with ARM processor > (Apple M1) > - > > Key: OAK-9796 > URL: https://issues.apache.org/jira/browse/OAK-9796 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: segment-aws >Reporter: Thomas Mueller >Priority: Major > Labels: arm > Fix For: 1.60.0 > > > I'm can't build oak-segment-remote with my new laptop (Apple M1 chip) due to > https://github.com/kstyrc/embedded-redis/issues/51 - looks like > https://github.com/kstyrc/embedded-redis is used, which uses an ancient > version of Redis. > There is a fork of https://github.com/kstyrc/embedded-redis that seems more > up-to-date: https://github.com/ozimov/embedded-redis. The last commit there > was in 2020. The issue https://github.com/kstyrc/embedded-redis/issues/51 was > fixed a bit later. So switching to that embedded Redis version doesn't > resolve the issue either. > If Redis isn't available, then the test shouldn't fail... instead, the test > should be skipped. this is what we do for mongodb: if it isn't available, > then those tests are not run. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-9796) oak-segment-remote and oak-segment-aws Redis tests fail with ARM processor (Apple M1)
[ https://issues.apache.org/jira/browse/OAK-9796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17787951#comment-17787951 ] Marcel Reutegger commented on OAK-9796: --- Merged [#1218|https://github.com/apache/jackrabbit-oak/pull/1218]. Created a new PR that skips the test if Redis cannot be started: https://github.com/apache/jackrabbit-oak/pull/1221 > oak-segment-remote and oak-segment-aws Redis tests fail with ARM processor > (Apple M1) > - > > Key: OAK-9796 > URL: https://issues.apache.org/jira/browse/OAK-9796 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: segment-aws >Reporter: Thomas Mueller >Priority: Major > Labels: arm > Fix For: 1.42.0, 1.22.11 > > > I'm can't build oak-segment-remote with my new laptop (Apple M1 chip) due to > https://github.com/kstyrc/embedded-redis/issues/51 - looks like > https://github.com/kstyrc/embedded-redis is used, which uses an ancient > version of Redis. > There is a fork of https://github.com/kstyrc/embedded-redis that seems more > up-to-date: https://github.com/ozimov/embedded-redis. The last commit there > was in 2020. The issue https://github.com/kstyrc/embedded-redis/issues/51 was > fixed a bit later. So switching to that embedded Redis version doesn't > resolve the issue either. > If Redis isn't available, then the test shouldn't fail... instead, the test > should be skipped. this is what we do for mongodb: if it isn't available, > then those tests are not run. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-9796) oak-segment-remote and oak-segment-aws Redis tests fail with ARM processor (Apple M1)
[ https://issues.apache.org/jira/browse/OAK-9796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17786708#comment-17786708 ] Marcel Reutegger commented on OAK-9796: --- PersistentRedisCacheTest now also fails on Mac OS Sonoma with Intel processor. Proposed fix switches to a more recent version/fork of embedded-redis: https://github.com/apache/jackrabbit-oak/pull/1218 > oak-segment-remote and oak-segment-aws Redis tests fail with ARM processor > (Apple M1) > - > > Key: OAK-9796 > URL: https://issues.apache.org/jira/browse/OAK-9796 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: segment-aws >Reporter: Thomas Mueller >Priority: Major > Labels: arm > Fix For: 1.42.0, 1.22.11 > > > I'm can't build oak-segment-remote with my new laptop (Apple M1 chip) due to > https://github.com/kstyrc/embedded-redis/issues/51 - looks like > https://github.com/kstyrc/embedded-redis is used, which uses an ancient > version of Redis. > There is a fork of https://github.com/kstyrc/embedded-redis that seems more > up-to-date: https://github.com/ozimov/embedded-redis. The last commit there > was in 2020. The issue https://github.com/kstyrc/embedded-redis/issues/51 was > fixed a bit later. So switching to that embedded Redis version doesn't > resolve the issue either. > If Redis isn't available, then the test shouldn't fail... instead, the test > should be skipped. this is what we do for mongodb: if it isn't available, > then those tests are not run. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10514) Utility method to remove unmerged branch changes
[ https://issues.apache.org/jira/browse/OAK-10514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved OAK-10514. Fix Version/s: 1.60.0 Resolution: Fixed Merged the PR. > Utility method to remove unmerged branch changes > > > Key: OAK-10514 > URL: https://issues.apache.org/jira/browse/OAK-10514 > Project: Jackrabbit Oak > Issue Type: Task > Components: run >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Fix For: 1.60.0 > > > Work on detailed revision garbage collection is still in progress. Until this > is finished a utility method in oak-mongo.js would be useful to remove > unmerged branch changes on a document. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10514) Utility method to remove unmerged branch changes
[ https://issues.apache.org/jira/browse/OAK-10514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1330#comment-1330 ] Marcel Reutegger commented on OAK-10514: Proposed implementation: https://github.com/apache/jackrabbit-oak/pull/1173 > Utility method to remove unmerged branch changes > > > Key: OAK-10514 > URL: https://issues.apache.org/jira/browse/OAK-10514 > Project: Jackrabbit Oak > Issue Type: Task > Components: run >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > > Work on detailed revision garbage collection is still in progress. Until this > is finished a utility method in oak-mongo.js would be useful to remove > unmerged branch changes on a document. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10514) Utility method to remove unmerged branch changes
Marcel Reutegger created OAK-10514: -- Summary: Utility method to remove unmerged branch changes Key: OAK-10514 URL: https://issues.apache.org/jira/browse/OAK-10514 Project: Jackrabbit Oak Issue Type: Task Components: run Reporter: Marcel Reutegger Assignee: Marcel Reutegger Work on detailed revision garbage collection is still in progress. Until this is finished a utility method in oak-mongo.js would be useful to remove unmerged branch changes on a document. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10499) Node bundling may resurrect node
[ https://issues.apache.org/jira/browse/OAK-10499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17776263#comment-17776263 ] Marcel Reutegger commented on OAK-10499: Created a draft PR with an ignored test that reproduces the issue: https://github.com/apache/jackrabbit-oak/pull/1160 > Node bundling may resurrect node > > > Key: OAK-10499 > URL: https://issues.apache.org/jira/browse/OAK-10499 > Project: Jackrabbit Oak > Issue Type: Bug > Components: documentmk >Reporter: Marcel Reutegger >Priority: Major > > In some cases the DocumentNodeStore node bundling features may resurrect > nodes that have been deleted. The issue happens when the following conditions > are met: > - The repository contains a node structure with bundled nodes > - There is a non-bundled node below a bundled node > - The node structure is removed with a clusterId different from the one used > when the nodes were created > - The node structure is partially re-created with a primary type that is not > configured for node bundling and with a clusterId different from the one used > when the nodes were removed. > After this sequence the non-bundled descendant node is resurrected, even > though it was not recreated. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OAK-10499) Node bundling may resurrect node
[ https://issues.apache.org/jira/browse/OAK-10499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-10499: --- Description: In some cases the DocumentNodeStore node bundling features may resurrect nodes that have been deleted. The issue happens when the following conditions are met: - The repository contains a node structure with bundled nodes - There is a non-bundled node below a bundled node - The node structure is removed with a clusterId different from the one used when the nodes were created - The node structure is partially re-created with a primary type that is not configured for node bundling and with a clusterId different from the one used when the nodes were removed. After this sequence the non-bundled descendant node is resurrected, even though it was not recreated. was: In some cases the DocumentNodeStore node bundling features may resurrect nodes that have been deleted. The issue happens when the following conditions are met: - The repository contains a node structure with bundled nodes - There is a non-bundled node below a bundled node - The node structure is removed with a clusterId different from the one used when the nodes were created - The node structure is partially re-created with a primary type that is not configured for node bundling and with a clusterId different from the one used when the nodes were removed. After this sequence the non-bundled descendant node is resurrected, even though it was not recreated. > Node bundling may resurrect node > > > Key: OAK-10499 > URL: https://issues.apache.org/jira/browse/OAK-10499 > Project: Jackrabbit Oak > Issue Type: Bug > Components: documentmk >Reporter: Marcel Reutegger >Priority: Major > > In some cases the DocumentNodeStore node bundling features may resurrect > nodes that have been deleted. The issue happens when the following conditions > are met: > - The repository contains a node structure with bundled nodes > - There is a non-bundled node below a bundled node > - The node structure is removed with a clusterId different from the one used > when the nodes were created > - The node structure is partially re-created with a primary type that is not > configured for node bundling and with a clusterId different from the one used > when the nodes were removed. > After this sequence the non-bundled descendant node is resurrected, even > though it was not recreated. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10499) Node bundling may resurrect node
Marcel Reutegger created OAK-10499: -- Summary: Node bundling may resurrect node Key: OAK-10499 URL: https://issues.apache.org/jira/browse/OAK-10499 Project: Jackrabbit Oak Issue Type: Bug Components: documentmk Reporter: Marcel Reutegger In some cases the DocumentNodeStore node bundling features may resurrect nodes that have been deleted. The issue happens when the following conditions are met: - The repository contains a node structure with bundled nodes - There is a non-bundled node below a bundled node - The node structure is removed with a clusterId different from the one used when the nodes were created - The node structure is partially re-created with a primary type that is not configured for node bundling and with a clusterId different from the one used when the nodes were removed. After this sequence the non-bundled descendant node is resurrected, even though it was not recreated. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-9922) segment-tar: parallel compaction
[ https://issues.apache.org/jira/browse/OAK-9922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17773168#comment-17773168 ] Marcel Reutegger commented on OAK-9922: --- bq. I believe this is undesirable I agree. oak-core makes use of the NodeStore API in oak-store-spi and oak-segment-tar is an implementation of this API. It doesn't yet introduce a cyclic dependency, but reduces room for manoeuvre. > segment-tar: parallel compaction > > > Key: OAK-9922 > URL: https://issues.apache.org/jira/browse/OAK-9922 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: segment-tar >Reporter: Lucas Weitzendorf >Assignee: Andrei Dulceanu >Priority: Major > Fix For: 1.58.0 > > > Add ability to parallelize compaction over subtrees with multiple threads. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OAK-10432) DocumentStoreIndexerIT failures
[
https://issues.apache.org/jira/browse/OAK-10432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger updated OAK-10432:
---
Priority: Major (was: Minor)
These tests are still failing. Recent failures I noticed
https://ci-builds.apache.org/blue/organizations/jenkins/Jackrabbit%2Foak-trunk-pr/detail/issue%2Foak-10377/2/pipeline
I think the test should either be fixed or disabled.
> DocumentStoreIndexerIT failures
> ---
>
> Key: OAK-10432
> URL: https://issues.apache.org/jira/browse/OAK-10432
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: oak-run
>Reporter: Marcel Reutegger
>Assignee: Mohit Kataria
>Priority: Major
>
> Tests related to parallel indexing in DocumentStoreIndexerIT fail frequently
> on Jenkins. Output from recent failures:
> {noformat}
> [ERROR] Tests run: 6, Failures: 2, Errors: 0, Skipped: 0, Time elapsed:
> 123.584 s <<< FAILURE! - in
> org.apache.jackrabbit.oak.index.DocumentStoreIndexerIT
> [ERROR]
> parallelReindex(org.apache.jackrabbit.oak.index.DocumentStoreIndexerIT) Time
> elapsed: 33.292 s <<< FAILURE!
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:87)
> at org.junit.Assert.assertTrue(Assert.java:42)
> at org.junit.Assert.assertFalse(Assert.java:65)
> at org.junit.Assert.assertFalse(Assert.java:75)
> at
> org.apache.jackrabbit.oak.index.DocumentStoreIndexerIT.parallelReindexInternal(DocumentStoreIndexerIT.java:265)
> at
> org.apache.jackrabbit.oak.index.DocumentStoreIndexerIT.parallelReindex(DocumentStoreIndexerIT.java:176)
> ...
> [ERROR]
> parallelReindexWithLZ4(org.apache.jackrabbit.oak.index.DocumentStoreIndexerIT)
> Time elapsed: 29.313 s <<< FAILURE!
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:87)
> at org.junit.Assert.assertTrue(Assert.java:42)
> at org.junit.Assert.assertFalse(Assert.java:65)
> at org.junit.Assert.assertFalse(Assert.java:75)
> at
> org.apache.jackrabbit.oak.index.DocumentStoreIndexerIT.parallelReindexInternal(DocumentStoreIndexerIT.java:265)
> at
> org.apache.jackrabbit.oak.index.DocumentStoreIndexerIT.parallelReindexWithLZ4(DocumentStoreIndexerIT.java:184)
> {noformat}
> See also previously reported issue OAK-10381.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-10371) oak-segment-azure/oak-blob-cloud-azure require provided Guava, embed it instead
[ https://issues.apache.org/jira/browse/OAK-10371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17764034#comment-17764034 ] Marcel Reutegger commented on OAK-10371: bq. Why can't you replace the component annotations in just this project? I tried that, but then the generated org.apache.jackrabbit.oak.plugins.blob.datastore.AzureDataStore.xml does not contain a reference to StatisticsProvider. I assume this is because we disabled the SCR plugin and the StatisticsProvider reference is in base class AbstractDataStoreService (in a different bundle) using SCR annotations. > oak-segment-azure/oak-blob-cloud-azure require provided Guava, embed it > instead > --- > > Key: OAK-10371 > URL: https://issues.apache.org/jira/browse/OAK-10371 > Project: Jackrabbit Oak > Issue Type: Task > Components: blob-cloud-azure, segment-azure >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Critical > > These components require Guava due to their dependency on > microsoft-azure-keyvault-core. That dependency is embedded, but Guava is not. > Choices: > - get microsoft-azure-keyvault-core fixed not to use Guava (unlikely, but see > https://github.com/Azure/azure-sdk-for-java/issues/26846) > - embed Guava > - make sure that the OSGi import statement is as relaxed as possible (note > that, for historic reasons, our components for now are likely used in > environments using Guava 15) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (OAK-10432) DocumentStoreIndexerIT failures
[
https://issues.apache.org/jira/browse/OAK-10432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger reassigned OAK-10432:
--
Assignee: Mohit Kataria
[~tihom88], assigning this to you because you worked on OAK-10381.
> DocumentStoreIndexerIT failures
> ---
>
> Key: OAK-10432
> URL: https://issues.apache.org/jira/browse/OAK-10432
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: oak-run
>Reporter: Marcel Reutegger
>Assignee: Mohit Kataria
>Priority: Minor
>
> Tests related to parallel indexing in DocumentStoreIndexerIT fail frequently
> on Jenkins. Output from recent failures:
> {noformat}
> [ERROR] Tests run: 6, Failures: 2, Errors: 0, Skipped: 0, Time elapsed:
> 123.584 s <<< FAILURE! - in
> org.apache.jackrabbit.oak.index.DocumentStoreIndexerIT
> [ERROR]
> parallelReindex(org.apache.jackrabbit.oak.index.DocumentStoreIndexerIT) Time
> elapsed: 33.292 s <<< FAILURE!
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:87)
> at org.junit.Assert.assertTrue(Assert.java:42)
> at org.junit.Assert.assertFalse(Assert.java:65)
> at org.junit.Assert.assertFalse(Assert.java:75)
> at
> org.apache.jackrabbit.oak.index.DocumentStoreIndexerIT.parallelReindexInternal(DocumentStoreIndexerIT.java:265)
> at
> org.apache.jackrabbit.oak.index.DocumentStoreIndexerIT.parallelReindex(DocumentStoreIndexerIT.java:176)
> ...
> [ERROR]
> parallelReindexWithLZ4(org.apache.jackrabbit.oak.index.DocumentStoreIndexerIT)
> Time elapsed: 29.313 s <<< FAILURE!
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:87)
> at org.junit.Assert.assertTrue(Assert.java:42)
> at org.junit.Assert.assertFalse(Assert.java:65)
> at org.junit.Assert.assertFalse(Assert.java:75)
> at
> org.apache.jackrabbit.oak.index.DocumentStoreIndexerIT.parallelReindexInternal(DocumentStoreIndexerIT.java:265)
> at
> org.apache.jackrabbit.oak.index.DocumentStoreIndexerIT.parallelReindexWithLZ4(DocumentStoreIndexerIT.java:184)
> {noformat}
> See also previously reported issue OAK-10381.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-10413) DocumentStoreIndexerIT hanging
[
https://issues.apache.org/jira/browse/OAK-10413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17762585#comment-17762585
]
Marcel Reutegger commented on OAK-10413:
Created OAK-10432.
> DocumentStoreIndexerIT hanging
> --
>
> Key: OAK-10413
> URL: https://issues.apache.org/jira/browse/OAK-10413
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: documentmk, run
>Reporter: Julian Reschke
>Priority: Major
>
> {noformat}
> [INFO] Running org.apache.jackrabbit.oak.index.DocumentStoreIndexerIT
> [WARNING] Corrupted STDOUT by directly writing to native stream in forked JVM
> 1. See FAQ web page and the dump file
> /home/jenkins/jenkins-agent/workspace/Jackrabbit/jackrabbit-oak-trunk/oak-run/target/failsafe-reports/2023-08-22T13-46-32_129-jvmRun1.dumpstream
> {noformat}
> ...and then eventually times out.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (OAK-10413) DocumentStoreIndexerIT hanging
[
https://issues.apache.org/jira/browse/OAK-10413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger resolved OAK-10413.
Fix Version/s: 1.58.0
Resolution: Fixed
> DocumentStoreIndexerIT hanging
> --
>
> Key: OAK-10413
> URL: https://issues.apache.org/jira/browse/OAK-10413
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: documentmk, run
>Reporter: Julian Reschke
>Priority: Major
> Fix For: 1.58.0
>
>
> {noformat}
> [INFO] Running org.apache.jackrabbit.oak.index.DocumentStoreIndexerIT
> [WARNING] Corrupted STDOUT by directly writing to native stream in forked JVM
> 1. See FAQ web page and the dump file
> /home/jenkins/jenkins-agent/workspace/Jackrabbit/jackrabbit-oak-trunk/oak-run/target/failsafe-reports/2023-08-22T13-46-32_129-jvmRun1.dumpstream
> {noformat}
> ...and then eventually times out.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (OAK-10432) DocumentStoreIndexerIT failures
Marcel Reutegger created OAK-10432:
--
Summary: DocumentStoreIndexerIT failures
Key: OAK-10432
URL: https://issues.apache.org/jira/browse/OAK-10432
Project: Jackrabbit Oak
Issue Type: Bug
Components: oak-run
Reporter: Marcel Reutegger
Tests related to parallel indexing in DocumentStoreIndexerIT fail frequently on
Jenkins. Output from recent failures:
{noformat}
[ERROR] Tests run: 6, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 123.584
s <<< FAILURE! - in org.apache.jackrabbit.oak.index.DocumentStoreIndexerIT
[ERROR] parallelReindex(org.apache.jackrabbit.oak.index.DocumentStoreIndexerIT)
Time elapsed: 33.292 s <<< FAILURE!
java.lang.AssertionError
at org.junit.Assert.fail(Assert.java:87)
at org.junit.Assert.assertTrue(Assert.java:42)
at org.junit.Assert.assertFalse(Assert.java:65)
at org.junit.Assert.assertFalse(Assert.java:75)
at
org.apache.jackrabbit.oak.index.DocumentStoreIndexerIT.parallelReindexInternal(DocumentStoreIndexerIT.java:265)
at
org.apache.jackrabbit.oak.index.DocumentStoreIndexerIT.parallelReindex(DocumentStoreIndexerIT.java:176)
...
[ERROR]
parallelReindexWithLZ4(org.apache.jackrabbit.oak.index.DocumentStoreIndexerIT)
Time elapsed: 29.313 s <<< FAILURE!
java.lang.AssertionError
at org.junit.Assert.fail(Assert.java:87)
at org.junit.Assert.assertTrue(Assert.java:42)
at org.junit.Assert.assertFalse(Assert.java:65)
at org.junit.Assert.assertFalse(Assert.java:75)
at
org.apache.jackrabbit.oak.index.DocumentStoreIndexerIT.parallelReindexInternal(DocumentStoreIndexerIT.java:265)
at
org.apache.jackrabbit.oak.index.DocumentStoreIndexerIT.parallelReindexWithLZ4(DocumentStoreIndexerIT.java:184)
{noformat}
See also previously reported issue OAK-10381.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-10413) DocumentStoreIndexerIT hanging
[
https://issues.apache.org/jira/browse/OAK-10413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17762583#comment-17762583
]
Marcel Reutegger commented on OAK-10413:
It is failing, but at least not hanging anymore as reported in this issue. The
test failures were also reported in OAK-10381, but it doesn't look like the
test issue is fixed. I'm going to create a new issue, because OAK-10381 was
resolved and marked fixed in 1.56.0, which is already released.
> DocumentStoreIndexerIT hanging
> --
>
> Key: OAK-10413
> URL: https://issues.apache.org/jira/browse/OAK-10413
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: documentmk, run
>Reporter: Julian Reschke
>Priority: Major
>
> {noformat}
> [INFO] Running org.apache.jackrabbit.oak.index.DocumentStoreIndexerIT
> [WARNING] Corrupted STDOUT by directly writing to native stream in forked JVM
> 1. See FAQ web page and the dump file
> /home/jenkins/jenkins-agent/workspace/Jackrabbit/jackrabbit-oak-trunk/oak-run/target/failsafe-reports/2023-08-22T13-46-32_129-jvmRun1.dumpstream
> {noformat}
> ...and then eventually times out.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-10413) DocumentStoreIndexerIT hanging
[
https://issues.apache.org/jira/browse/OAK-10413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17762065#comment-17762065
]
Marcel Reutegger commented on OAK-10413:
PR #1099 (including changes from OAK-10427) ran all tests successfully. I
merged the changes into trunk. Let's wait for some more runs until we resolve
this issue.
> DocumentStoreIndexerIT hanging
> --
>
> Key: OAK-10413
> URL: https://issues.apache.org/jira/browse/OAK-10413
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: documentmk, run
>Reporter: Julian Reschke
>Priority: Major
>
> {noformat}
> [INFO] Running org.apache.jackrabbit.oak.index.DocumentStoreIndexerIT
> [WARNING] Corrupted STDOUT by directly writing to native stream in forked JVM
> 1. See FAQ web page and the dump file
> /home/jenkins/jenkins-agent/workspace/Jackrabbit/jackrabbit-oak-trunk/oak-run/target/failsafe-reports/2023-08-22T13-46-32_129-jvmRun1.dumpstream
> {noformat}
> ...and then eventually times out.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (OAK-10428) UserPrincipalProvider updates group cache on every login
[
https://issues.apache.org/jira/browse/OAK-10428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17761997#comment-17761997
]
Marcel Reutegger edited comment on OAK-10428 at 9/5/23 9:08 AM:
bq. In case a group membership cache is stored at the principal, some
properties are updated on every access, and committed.
I noticed this as well in some cases, but the cache is not updated on every
access. There is still a problematic pattern in my view. Once the cache for a
principal reaches the end of its TTL, there is a thundering herd problem.
Multiple requests coming in at roughly the same time will all try to update the
cache and most of them will run into conflicts.
I think it would be better if only one thread updates the cache, while all
other just use the slightly outdated value currently in the cache.
was (Author: mreutegg):
bq. In case a group membership cache is stored at the principal, some
properties are updated on every access, and committed.
I noticed this as well in some cases, but the cache is not updated on every
access. There is still a problematic pattern in my view. Once the cache for a
principal reaches the end of its TTL, there is a thundering herd problem.
Multiple requests coming in at roughly the same time will all try to update the
cache and most of them will run into conflicts.
> UserPrincipalProvider updates group cache on every login
>
>
> Key: OAK-10428
> URL: https://issues.apache.org/jira/browse/OAK-10428
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: authorization-principalbased
>Affects Versions: 1.56.0
>Reporter: Joerg Hoh
>Priority: Major
>
> Under traffic (by a single user) I see in a DocumentNodeStore setup this
> stacktrace for a lot of requests:
> {noformat}
> "qtp2052801890-41390" #41390 prio=5 os_prio=0 cpu=19882.72ms elapsed=3024.20s
> tid=0x564321465800 nid=0x3ec2a waiting on condition [0x7f633f55f000]
>java.lang.Thread.State: WAITING (parking)
> at jdk.internal.misc.Unsafe.park(java.base@11.0.15/Native Method)
> - parking to wait for <0x0006a0cac5f0> (a
> java.util.concurrent.locks.ReentrantLock$NonfairSync)
> at
> java.util.concurrent.locks.LockSupport.park(java.base@11.0.15/LockSupport.java:194)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(java.base@11.0.15/AbstractQueuedSynchronizer.java:885)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(java.base@11.0.15/AbstractQueuedSynchronizer.java:917)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(java.base@11.0.15/AbstractQueuedSynchronizer.java:1240)
> at
> java.util.concurrent.locks.ReentrantLock.lock(java.base@11.0.15/ReentrantLock.java:267)
> at
> org.apache.jackrabbit.oak.plugins.document.locks.StripedNodeDocumentLocks.acquire(StripedNodeDocumentLocks.java:39)
> at
> org.apache.jackrabbit.oak.plugins.document.mongo.MongoDocumentStore.findAndModify(MongoDocumentStore.java:1054)
> at
> org.apache.jackrabbit.oak.plugins.document.mongo.MongoDocumentStore.findAndUpdate(MongoDocumentStore.java:1610)
> at
> org.apache.jackrabbit.oak.plugins.document.util.LeaseCheckDocumentStoreWrapper.findAndUpdate(LeaseCheckDocumentStoreWrapper.java:151)
> at
> org.apache.jackrabbit.oak.plugins.document.Collision.markCommitRoot(Collision.java:201)
> at
> org.apache.jackrabbit.oak.plugins.document.Collision.mark(Collision.java:85)
> at
> org.apache.jackrabbit.oak.plugins.document.Commit.checkConflicts(Commit.java:604)
> at
> org.apache.jackrabbit.oak.plugins.document.Commit.checkConflicts(Commit.java:642)
> at
> org.apache.jackrabbit.oak.plugins.document.Commit.applyToDocumentStore(Commit.java:372)
> at
> org.apache.jackrabbit.oak.plugins.document.Commit.applyToDocumentStoreWithTiming(Commit.java:278)
> at
> org.apache.jackrabbit.oak.plugins.document.Commit.applyToDocumentStore(Commit.java:262)
> at
> org.apache.jackrabbit.oak.plugins.document.Commit.applyInternal(Commit.java:236)
> at
> org.apache.jackrabbit.oak.plugins.document.Commit.apply(Commit.java:224)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch.persist(DocumentNodeStoreBranch.java:321)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch.persist(DocumentNodeStoreBranch.java:283)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch$InMemory.merge(DocumentNodeStoreBranch.java:553)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch.merge0(DocumentNodeStoreBranch.java:197)
> at
> org.a
[jira] [Commented] (OAK-10428) UserPrincipalProvider updates group cache on every login
[
https://issues.apache.org/jira/browse/OAK-10428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17761997#comment-17761997
]
Marcel Reutegger commented on OAK-10428:
bq. In case a group membership cache is stored at the principal, some
properties are updated on every access, and committed.
I noticed this as well in some cases, but the cache is not updated on every
access. There is still a problematic pattern in my view. Once the cache for a
principal reaches the end of its TTL, there is a thundering herd problem.
Multiple requests coming in at roughly the same time will all try to update the
cache and most of them will run into conflicts.
> UserPrincipalProvider updates group cache on every login
>
>
> Key: OAK-10428
> URL: https://issues.apache.org/jira/browse/OAK-10428
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: authorization-principalbased
>Affects Versions: 1.56.0
>Reporter: Joerg Hoh
>Priority: Major
>
> Under traffic (by a single user) I see in a DocumentNodeStore setup this
> stacktrace for a lot of requests:
> {noformat}
> "qtp2052801890-41390" #41390 prio=5 os_prio=0 cpu=19882.72ms elapsed=3024.20s
> tid=0x564321465800 nid=0x3ec2a waiting on condition [0x7f633f55f000]
>java.lang.Thread.State: WAITING (parking)
> at jdk.internal.misc.Unsafe.park(java.base@11.0.15/Native Method)
> - parking to wait for <0x0006a0cac5f0> (a
> java.util.concurrent.locks.ReentrantLock$NonfairSync)
> at
> java.util.concurrent.locks.LockSupport.park(java.base@11.0.15/LockSupport.java:194)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(java.base@11.0.15/AbstractQueuedSynchronizer.java:885)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(java.base@11.0.15/AbstractQueuedSynchronizer.java:917)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(java.base@11.0.15/AbstractQueuedSynchronizer.java:1240)
> at
> java.util.concurrent.locks.ReentrantLock.lock(java.base@11.0.15/ReentrantLock.java:267)
> at
> org.apache.jackrabbit.oak.plugins.document.locks.StripedNodeDocumentLocks.acquire(StripedNodeDocumentLocks.java:39)
> at
> org.apache.jackrabbit.oak.plugins.document.mongo.MongoDocumentStore.findAndModify(MongoDocumentStore.java:1054)
> at
> org.apache.jackrabbit.oak.plugins.document.mongo.MongoDocumentStore.findAndUpdate(MongoDocumentStore.java:1610)
> at
> org.apache.jackrabbit.oak.plugins.document.util.LeaseCheckDocumentStoreWrapper.findAndUpdate(LeaseCheckDocumentStoreWrapper.java:151)
> at
> org.apache.jackrabbit.oak.plugins.document.Collision.markCommitRoot(Collision.java:201)
> at
> org.apache.jackrabbit.oak.plugins.document.Collision.mark(Collision.java:85)
> at
> org.apache.jackrabbit.oak.plugins.document.Commit.checkConflicts(Commit.java:604)
> at
> org.apache.jackrabbit.oak.plugins.document.Commit.checkConflicts(Commit.java:642)
> at
> org.apache.jackrabbit.oak.plugins.document.Commit.applyToDocumentStore(Commit.java:372)
> at
> org.apache.jackrabbit.oak.plugins.document.Commit.applyToDocumentStoreWithTiming(Commit.java:278)
> at
> org.apache.jackrabbit.oak.plugins.document.Commit.applyToDocumentStore(Commit.java:262)
> at
> org.apache.jackrabbit.oak.plugins.document.Commit.applyInternal(Commit.java:236)
> at
> org.apache.jackrabbit.oak.plugins.document.Commit.apply(Commit.java:224)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch.persist(DocumentNodeStoreBranch.java:321)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch.persist(DocumentNodeStoreBranch.java:283)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch$InMemory.merge(DocumentNodeStoreBranch.java:553)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch.merge0(DocumentNodeStoreBranch.java:197)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch.merge(DocumentNodeStoreBranch.java:121)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentRootBuilder.merge(DocumentRootBuilder.java:170)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.merge(DocumentNodeStore.java:2067)
> at
> org.apache.jackrabbit.oak.composite.CompositeNodeStore.merge(CompositeNodeStore.java:153)
> at
> org.apache.jackrabbit.oak.core.MutableRoot.commit(MutableRoot.java:262)
> at
> org.apache.jackrabbit.oak.security.user.UserPrincipalProvider.cacheGroups(UserPrincipalProvider.java:318)
> at
> org.apache.jackrabbit.oak.security.user.Use
[jira] [Commented] (OAK-10425) Ability to remove mixin type without read permission on jcr:mixinTypes property
[ https://issues.apache.org/jira/browse/OAK-10425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17761968#comment-17761968 ] Marcel Reutegger commented on OAK-10425: https://github.com/apache/jackrabbit-oak/pull/1100 adds an ignored test. > Ability to remove mixin type without read permission on jcr:mixinTypes > property > --- > > Key: OAK-10425 > URL: https://issues.apache.org/jira/browse/OAK-10425 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: jcr >Reporter: Marcel Reutegger >Priority: Minor > > When a session does not have read permission on property jcr:mixinTypes, then > Node.removeMixin(String) will fail with an exception. This is inconsistent > with other behaviour related to node type information. See OAK-2441 and > OAK-10334. > The call should succeed if the session has permission to write jcr:mixinTypes. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10427) Clear cache on NodeDocumentCache close
[ https://issues.apache.org/jira/browse/OAK-10427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved OAK-10427. Fix Version/s: 1.58.0 Resolution: Fixed Merged the PR. > Clear cache on NodeDocumentCache close > -- > > Key: OAK-10427 > URL: https://issues.apache.org/jira/browse/OAK-10427 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: documentmk >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Fix For: 1.58.0 > > > The in-memory caches in NodeDocumentCache are currently not cleared on close > and a referenced NodeDocumentCache instance may still retain significant > memory after close. > In-memory caches should be cleared on close. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10334) Node.addMixin() may overwrite existing mixins
[ https://issues.apache.org/jira/browse/OAK-10334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved OAK-10334. Fix Version/s: 1.58.0 Resolution: Fixed Merged the PR. > Node.addMixin() may overwrite existing mixins > - > > Key: OAK-10334 > URL: https://issues.apache.org/jira/browse/OAK-10334 > Project: Jackrabbit Oak > Issue Type: Bug > Components: jcr >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Major > Fix For: 1.58.0 > > > A Session lacking permission to read property jcr:mixinTypes, but permission > to write will overwrite existing mixins when calling Node.addMixin(). > The implementation does not check if the session has permission to read > jcr:mixinTypes and assumes there are no existing values when the session does > not have permission. The result is a jcr:mixinTypes property with only a > single value passed to addMixin(). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10413) DocumentStoreIndexerIT hanging
[
https://issues.apache.org/jira/browse/OAK-10413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17761867#comment-17761867
]
Marcel Reutegger commented on OAK-10413:
Proposed changes to PurgeOldIndexVersionIT:
https://github.com/apache/jackrabbit-oak/pull/1099
> DocumentStoreIndexerIT hanging
> --
>
> Key: OAK-10413
> URL: https://issues.apache.org/jira/browse/OAK-10413
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: documentmk, run
>Reporter: Julian Reschke
>Priority: Major
>
> {noformat}
> [INFO] Running org.apache.jackrabbit.oak.index.DocumentStoreIndexerIT
> [WARNING] Corrupted STDOUT by directly writing to native stream in forked JVM
> 1. See FAQ web page and the dump file
> /home/jenkins/jenkins-agent/workspace/Jackrabbit/jackrabbit-oak-trunk/oak-run/target/failsafe-reports/2023-08-22T13-46-32_129-jvmRun1.dumpstream
> {noformat}
> ...and then eventually times out.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-10427) Clear cache on NodeDocumentCache close
[ https://issues.apache.org/jira/browse/OAK-10427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17761866#comment-17761866 ] Marcel Reutegger commented on OAK-10427: Proposed changes in https://github.com/apache/jackrabbit-oak/pull/1098 > Clear cache on NodeDocumentCache close > -- > > Key: OAK-10427 > URL: https://issues.apache.org/jira/browse/OAK-10427 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: documentmk >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > > The in-memory caches in NodeDocumentCache are currently not cleared on close > and a referenced NodeDocumentCache instance may still retain significant > memory after close. > In-memory caches should be cleared on close. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10413) DocumentStoreIndexerIT hanging
[
https://issues.apache.org/jira/browse/OAK-10413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17761865#comment-17761865
]
Marcel Reutegger commented on OAK-10413:
See OAK-10427 for the changes related to MongoDocumentStore. The actual change
is in NodeDocumentCache.
> DocumentStoreIndexerIT hanging
> --
>
> Key: OAK-10413
> URL: https://issues.apache.org/jira/browse/OAK-10413
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: documentmk, run
>Reporter: Julian Reschke
>Priority: Major
>
> {noformat}
> [INFO] Running org.apache.jackrabbit.oak.index.DocumentStoreIndexerIT
> [WARNING] Corrupted STDOUT by directly writing to native stream in forked JVM
> 1. See FAQ web page and the dump file
> /home/jenkins/jenkins-agent/workspace/Jackrabbit/jackrabbit-oak-trunk/oak-run/target/failsafe-reports/2023-08-22T13-46-32_129-jvmRun1.dumpstream
> {noformat}
> ...and then eventually times out.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (OAK-10427) Clear cache on NodeDocumentCache close
Marcel Reutegger created OAK-10427: -- Summary: Clear cache on NodeDocumentCache close Key: OAK-10427 URL: https://issues.apache.org/jira/browse/OAK-10427 Project: Jackrabbit Oak Issue Type: Improvement Components: documentmk Reporter: Marcel Reutegger Assignee: Marcel Reutegger The in-memory caches in NodeDocumentCache are currently not cleared on close and a referenced NodeDocumentCache instance may still retain significant memory after close. In-memory caches should be cleared on close. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10413) DocumentStoreIndexerIT hanging
[
https://issues.apache.org/jira/browse/OAK-10413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17761864#comment-17761864
]
Marcel Reutegger commented on OAK-10413:
Looks like there is not much that can be done about FlatFileStore instances.
There is a list of FlatFileStore created by one of the tests with 24 instances.
The CachingSegmentReader are opened by Persistence used in
PurgeOldIndexVersionIT. The tests in there do not close Persistence in some
cases.
The MongoDocumentStore instances are actually closed, but referenced by
TraverseWithSortStrategy.MemoryListener. This (non-static) inner class
indirectly references a MongoDocumentStore. These listeners are added but never
removed from the MemoryMXBean. A quick fix would be to reduce memory of closed
MongoDocumentStore instances. Currently they are quite heavy weight because
caches they reference are not cleared on close/dispose.
With the two changes mentioned above, I can reliable run oak-run integration
tests in the sequence seen on Jenkins without a memory issue.
> DocumentStoreIndexerIT hanging
> --
>
> Key: OAK-10413
> URL: https://issues.apache.org/jira/browse/OAK-10413
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: documentmk, run
>Reporter: Julian Reschke
>Priority: Major
>
> {noformat}
> [INFO] Running org.apache.jackrabbit.oak.index.DocumentStoreIndexerIT
> [WARNING] Corrupted STDOUT by directly writing to native stream in forked JVM
> 1. See FAQ web page and the dump file
> /home/jenkins/jenkins-agent/workspace/Jackrabbit/jackrabbit-oak-trunk/oak-run/target/failsafe-reports/2023-08-22T13-46-32_129-jvmRun1.dumpstream
> {noformat}
> ...and then eventually times out.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-10413) DocumentStoreIndexerIT hanging
[
https://issues.apache.org/jira/browse/OAK-10413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17761793#comment-17761793
]
Marcel Reutegger commented on OAK-10413:
The majority of memory is occupied by:
- 26 instances of FlatFileStore (144 MB)
- 6 instances of CachingSegmentReader (61 MB)
- 7 instances of MongoDocumentStore (44 MB)
I suspect some tests are not releasing resources.
> DocumentStoreIndexerIT hanging
> --
>
> Key: OAK-10413
> URL: https://issues.apache.org/jira/browse/OAK-10413
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: documentmk, run
>Reporter: Julian Reschke
>Priority: Major
>
> {noformat}
> [INFO] Running org.apache.jackrabbit.oak.index.DocumentStoreIndexerIT
> [WARNING] Corrupted STDOUT by directly writing to native stream in forked JVM
> 1. See FAQ web page and the dump file
> /home/jenkins/jenkins-agent/workspace/Jackrabbit/jackrabbit-oak-trunk/oak-run/target/failsafe-reports/2023-08-22T13-46-32_129-jvmRun1.dumpstream
> {noformat}
> ...and then eventually times out.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-10413) DocumentStoreIndexerIT hanging
[
https://issues.apache.org/jira/browse/OAK-10413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17761775#comment-17761775
]
Marcel Reutegger commented on OAK-10413:
I'm able to reproduce when running tests in the same sequence like Jenkins
does. Added the following test and then specified it on the command line with
-Dtest=MyTest.
{noformat}
@RunWith(Suite.class)
@Suite.SuiteClasses({
PurgeOldIndexVersionIT.class,
LuceneIndexCommandIT.class,
ReindexIT.class,
DocumentStoreIndexerIT.class
})
public class MyTest {
}
{noformat}
Analyzing the heap dump...
> DocumentStoreIndexerIT hanging
> --
>
> Key: OAK-10413
> URL: https://issues.apache.org/jira/browse/OAK-10413
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: documentmk, run
>Reporter: Julian Reschke
>Priority: Major
>
> {noformat}
> [INFO] Running org.apache.jackrabbit.oak.index.DocumentStoreIndexerIT
> [WARNING] Corrupted STDOUT by directly writing to native stream in forked JVM
> 1. See FAQ web page and the dump file
> /home/jenkins/jenkins-agent/workspace/Jackrabbit/jackrabbit-oak-trunk/oak-run/target/failsafe-reports/2023-08-22T13-46-32_129-jvmRun1.dumpstream
> {noformat}
> ...and then eventually times out.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-10334) Node.addMixin() may overwrite existing mixins
[ https://issues.apache.org/jira/browse/OAK-10334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17761702#comment-17761702 ] Marcel Reutegger commented on OAK-10334: Follow up issue regarding Node.removeMixin(String): OAK-10425 > Node.addMixin() may overwrite existing mixins > - > > Key: OAK-10334 > URL: https://issues.apache.org/jira/browse/OAK-10334 > Project: Jackrabbit Oak > Issue Type: Bug > Components: jcr >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Major > > A Session lacking permission to read property jcr:mixinTypes, but permission > to write will overwrite existing mixins when calling Node.addMixin(). > The implementation does not check if the session has permission to read > jcr:mixinTypes and assumes there are no existing values when the session does > not have permission. The result is a jcr:mixinTypes property with only a > single value passed to addMixin(). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OAK-10425) Ability to remove mixin type without read permission on jcr:mixinTypes property
[ https://issues.apache.org/jira/browse/OAK-10425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-10425: --- Component/s: jcr Description: When a session does not have read permission on property jcr:mixinTypes, then Node.removeMixin(String) will fail with an exception. This is inconsistent with other behaviour related to node type information. See OAK-2441 and OAK-10334. The call should succeed if the session has permission to write jcr:mixinTypes. Summary: Ability to remove mixin type without read permission on jcr:mixinTypes property (was: Ail) > Ability to remove mixin type without read permission on jcr:mixinTypes > property > --- > > Key: OAK-10425 > URL: https://issues.apache.org/jira/browse/OAK-10425 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: jcr >Reporter: Marcel Reutegger >Priority: Minor > > When a session does not have read permission on property jcr:mixinTypes, then > Node.removeMixin(String) will fail with an exception. This is inconsistent > with other behaviour related to node type information. See OAK-2441 and > OAK-10334. > The call should succeed if the session has permission to write jcr:mixinTypes. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10425) Ail
Marcel Reutegger created OAK-10425: -- Summary: Ail Key: OAK-10425 URL: https://issues.apache.org/jira/browse/OAK-10425 Project: Jackrabbit Oak Issue Type: Improvement Reporter: Marcel Reutegger -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10266) ClientIpFilterTest fails for localhost
[
https://issues.apache.org/jira/browse/OAK-10266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17760757#comment-17760757
]
Marcel Reutegger commented on OAK-10266:
With the following patch the test runs fine on my machine.
{noformat}
diff --git a/oak-parent/pom.xml b/oak-parent/pom.xml
index 6985e10fa3..b5af63b554 100644
--- a/oak-parent/pom.xml
+++ b/oak-parent/pom.xml
@@ -36,7 +36,7 @@
3.3.9
-Xmx512m
-${test.opts.coverage} ${test.opts.memory}
-XX:+HeapDumpOnOutOfMemoryError -Dupdate.limit=100
-Djava.awt.headless=true
+${test.opts.coverage} ${test.opts.memory}
-XX:+HeapDumpOnOutOfMemoryError -Dupdate.limit=100 -Djava.awt.headless=true
-Djava.net.preferIPv4Stack=true
false
true
0.0
{noformat}
But I rather think the test itself should be somehow improved to work on either
IP stack.
> ClientIpFilterTest fails for localhost
> --
>
> Key: OAK-10266
> URL: https://issues.apache.org/jira/browse/OAK-10266
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Reporter: Marcel Reutegger
>Priority: Minor
>
> ClientIpFilterTest fails on my machine for filters=localhost.
> The JVM returns an IP v6 address, which does not match the expected 127.0.0.1.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (OAK-10357) Path option for documentstore-check
[ https://issues.apache.org/jira/browse/OAK-10357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved OAK-10357. Fix Version/s: 1.56.0 Resolution: Fixed Merged the PR. > Path option for documentstore-check > --- > > Key: OAK-10357 > URL: https://issues.apache.org/jira/browse/OAK-10357 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: run >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Major > Fix For: 1.56.0 > > > The documentstore-check currently goes through the entire document store. Add > a path option that allows specifying paths to check. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10334) Node.addMixin() may overwrite existing mixins
[ https://issues.apache.org/jira/browse/OAK-10334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17758860#comment-17758860 ] Marcel Reutegger commented on OAK-10334: Based on review feedback in the PR the proposed fix now correctly updates jcr:mixinTypes even when the session does not have read permission on the property. This is consistent with the behaviour described in OAK-2441. > Node.addMixin() may overwrite existing mixins > - > > Key: OAK-10334 > URL: https://issues.apache.org/jira/browse/OAK-10334 > Project: Jackrabbit Oak > Issue Type: Bug > Components: jcr >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Major > > A Session lacking permission to read property jcr:mixinTypes, but permission > to write will overwrite existing mixins when calling Node.addMixin(). > The implementation does not check if the session has permission to read > jcr:mixinTypes and assumes there are no existing values when the session does > not have permission. The result is a jcr:mixinTypes property with only a > single value passed to addMixin(). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (OAK-10334) Node.addMixin() may overwrite existing mixins
[ https://issues.apache.org/jira/browse/OAK-10334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger reassigned OAK-10334: -- Assignee: Marcel Reutegger > Node.addMixin() may overwrite existing mixins > - > > Key: OAK-10334 > URL: https://issues.apache.org/jira/browse/OAK-10334 > Project: Jackrabbit Oak > Issue Type: Bug > Components: jcr >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Major > > A Session lacking permission to read property jcr:mixinTypes, but permission > to write will overwrite existing mixins when calling Node.addMixin(). > The implementation does not check if the session has permission to read > jcr:mixinTypes and assumes there are no existing values when the session does > not have permission. The result is a jcr:mixinTypes property with only a > single value passed to addMixin(). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10304) log registration of invalid namespace names
[
https://issues.apache.org/jira/browse/OAK-10304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17757305#comment-17757305
]
Marcel Reutegger commented on OAK-10304:
I would rather keep it simple and backport the code as is. If the log message
is too noisy for some users, they can disable the logger by configuration.
> log registration of invalid namespace names
> ---
>
> Key: OAK-10304
> URL: https://issues.apache.org/jira/browse/OAK-10304
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: core
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Major
> Labels: candidate_oak_1_22
> Fix For: 1.54.0
>
>
> Example:
> {noformat}
> diff --git
> a/oak-jcr/src/test/java/org/apache/jackrabbit/oak/jcr/RepositoryTest.java
> b/oak-jcr/src/test/java/org/apache/jackrabbit/oak/jcr/RepositoryTest.java
> index f113e4e0d2..7178a36f7f 100644
> --- a/oak-jcr/src/test/java/org/apache/jackrabbit/oak/jcr/RepositoryTest.java
> +++ b/oak-jcr/src/test/java/org/apache/jackrabbit/oak/jcr/RepositoryTest.java
> @@ -1996,6 +1996,24 @@ public class RepositoryTest extends
> AbstractRepositoryTest {
> assertFalse(asList(nsReg.getURIs()).contains("file:///foo"));
> }
> +@Test
> +public void testNamespaceNames() throws RepositoryException {
> +NamespaceRegistry nsReg =
> +getAdminSession().getWorkspace().getNamespaceRegistry();
> +
> +// valid
> +nsReg.registerNamespace("foo", "https://example.com";);
> +nsReg.unregisterNamespace("foo");
> +
> +// invalid
> +try {
> +nsReg.registerNamespace("foo", "example.com");
> +fail("should not register invalid namespace name");
> +} finally {
> +nsReg.unregisterNamespace("foo");
> +}
> +}
> {noformat}
> Note that name of nodes using invalid namespaces do have a valid "expanded
> form" variant
> (https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.2.5.1%20Expanded%20Form).
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-10357) Path option for documentstore-check
[ https://issues.apache.org/jira/browse/OAK-10357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17744189#comment-17744189 ] Marcel Reutegger commented on OAK-10357: Proposed changes in PR: https://github.com/apache/jackrabbit-oak/pull/1031 > Path option for documentstore-check > --- > > Key: OAK-10357 > URL: https://issues.apache.org/jira/browse/OAK-10357 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: run >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Major > > The documentstore-check currently goes through the entire document store. Add > a path option that allows specifying paths to check. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10357) Path option for documentstore-check
Marcel Reutegger created OAK-10357: -- Summary: Path option for documentstore-check Key: OAK-10357 URL: https://issues.apache.org/jira/browse/OAK-10357 Project: Jackrabbit Oak Issue Type: Improvement Components: run Reporter: Marcel Reutegger Assignee: Marcel Reutegger The documentstore-check currently goes through the entire document store. Add a path option that allows specifying paths to check. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10340) Child order not updated on source after move
[ https://issues.apache.org/jira/browse/OAK-10340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved OAK-10340. Fix Version/s: 1.54.0 Resolution: Fixed Merged PR into trunk. > Child order not updated on source after move > > > Key: OAK-10340 > URL: https://issues.apache.org/jira/browse/OAK-10340 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Fix For: 1.54.0 > > > The hidden child order property on the source parent of a move operation is > not updated when the moved node was orderable under the source parent. > The issue does not seem serious, because AbstractTree.getChildNames() is > quite lenient and will add children not present in :childOrder at the end of > the returned Iterable. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10340) Child order not updated on source after move
[ https://issues.apache.org/jira/browse/OAK-10340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17741510#comment-17741510 ] Marcel Reutegger commented on OAK-10340: The pull request also fixes another issue in MutableTree.moveTo(). The call to the underlying NodeBuilder.moveTo() may returns false. In this case, the MutableTree must not change state, but it currently does. It incorrectly changes its parent to the move target already before NodeBuilder.moveTo(). I added a test that exercises this scenario. > Child order not updated on source after move > > > Key: OAK-10340 > URL: https://issues.apache.org/jira/browse/OAK-10340 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > > The hidden child order property on the source parent of a move operation is > not updated when the moved node was orderable under the source parent. > The issue does not seem serious, because AbstractTree.getChildNames() is > quite lenient and will add children not present in :childOrder at the end of > the returned Iterable. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10340) Child order not updated on source after move
[ https://issues.apache.org/jira/browse/OAK-10340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17740203#comment-17740203 ] Marcel Reutegger commented on OAK-10340: Test to reproduce the issue and proposed changes in PR https://github.com/apache/jackrabbit-oak/pull/1017 > Child order not updated on source after move > > > Key: OAK-10340 > URL: https://issues.apache.org/jira/browse/OAK-10340 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > > The hidden child order property on the source parent of a move operation is > not updated when the moved node was orderable under the source parent. > The issue does not seem serious, because AbstractTree.getChildNames() is > quite lenient and will add children not present in :childOrder at the end of > the returned Iterable. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10340) Child order not updated on source after move
Marcel Reutegger created OAK-10340: -- Summary: Child order not updated on source after move Key: OAK-10340 URL: https://issues.apache.org/jira/browse/OAK-10340 Project: Jackrabbit Oak Issue Type: Bug Components: core Reporter: Marcel Reutegger Assignee: Marcel Reutegger The hidden child order property on the source parent of a move operation is not updated when the moved node was orderable under the source parent. The issue does not seem serious, because AbstractTree.getChildNames() is quite lenient and will add children not present in :childOrder at the end of the returned Iterable. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10334) Node.addMixin() may overwrite existing mixins
[ https://issues.apache.org/jira/browse/OAK-10334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17739476#comment-17739476 ] Marcel Reutegger commented on OAK-10334: Read and write are distinct permissions. There are aggregates that include both, but generally it is possible to deny read and allow write of an item. See also test in PR. > Node.addMixin() may overwrite existing mixins > - > > Key: OAK-10334 > URL: https://issues.apache.org/jira/browse/OAK-10334 > Project: Jackrabbit Oak > Issue Type: Bug > Components: jcr >Reporter: Marcel Reutegger >Priority: Major > > A Session lacking permission to read property jcr:mixinTypes, but permission > to write will overwrite existing mixins when calling Node.addMixin(). > The implementation does not check if the session has permission to read > jcr:mixinTypes and assumes there are no existing values when the session does > not have permission. The result is a jcr:mixinTypes property with only a > single value passed to addMixin(). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OAK-10294) Indexing job: add new Pipelined Strategy for dumping Mongo contents in preparation for reindexing
[ https://issues.apache.org/jira/browse/OAK-10294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-10294: --- Description: (was: [~nuno.santos] & [~nuno.santos], please set a fix version when an issue is resolved. I just did and set it to 1.54.0.) [~thomasm] & [~nuno.santos], please set a fix version when an issue is resolved. I just did and set it to 1.54.0. > Indexing job: add new Pipelined Strategy for dumping Mongo contents in > preparation for reindexing > - > > Key: OAK-10294 > URL: https://issues.apache.org/jira/browse/OAK-10294 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: indexing >Reporter: Nuno Santos >Priority: Major > Fix For: 1.54.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OAK-10294) Indexing job: add new Pipelined Strategy for dumping Mongo contents in preparation for reindexing
[ https://issues.apache.org/jira/browse/OAK-10294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-10294: --- Fix Version/s: 1.54.0 Description: [~nuno.santos] & [~nuno.santos], please set a fix version when an issue is resolved. I just did and set it to 1.54.0. > Indexing job: add new Pipelined Strategy for dumping Mongo contents in > preparation for reindexing > - > > Key: OAK-10294 > URL: https://issues.apache.org/jira/browse/OAK-10294 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: indexing >Reporter: Nuno Santos >Priority: Major > Fix For: 1.54.0 > > > [~nuno.santos] & [~nuno.santos], please set a fix version when an issue is > resolved. I just did and set it to 1.54.0. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10334) Node.addMixin() may overwrite existing mixins
[ https://issues.apache.org/jira/browse/OAK-10334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17739119#comment-17739119 ] Marcel Reutegger commented on OAK-10334: PR now contains a proposed fix. Adding a mixin type now also requires read permission on jcr:mixinTypes. [~angela], WDYT? > Node.addMixin() may overwrite existing mixins > - > > Key: OAK-10334 > URL: https://issues.apache.org/jira/browse/OAK-10334 > Project: Jackrabbit Oak > Issue Type: Bug > Components: jcr >Reporter: Marcel Reutegger >Priority: Major > > A Session lacking permission to read property jcr:mixinTypes, but permission > to write will overwrite existing mixins when calling Node.addMixin(). > The implementation does not check if the session has permission to read > jcr:mixinTypes and assumes there are no existing values when the session does > not have permission. The result is a jcr:mixinTypes property with only a > single value passed to addMixin(). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10334) Node.addMixin() may overwrite existing mixins
[ https://issues.apache.org/jira/browse/OAK-10334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17739102#comment-17739102 ] Marcel Reutegger commented on OAK-10334: Created draft PR with a test reproducing the issue: https://github.com/apache/jackrabbit-oak/pull/1011 > Node.addMixin() may overwrite existing mixins > - > > Key: OAK-10334 > URL: https://issues.apache.org/jira/browse/OAK-10334 > Project: Jackrabbit Oak > Issue Type: Bug > Components: jcr >Reporter: Marcel Reutegger >Priority: Major > > A Session lacking permission to read property jcr:mixinTypes, but permission > to write will overwrite existing mixins when calling Node.addMixin(). > The implementation does not check if the session has permission to read > jcr:mixinTypes and assumes there are no existing values when the session does > not have permission. The result is a jcr:mixinTypes property with only a > single value passed to addMixin(). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10334) Node.addMixin() may overwrite existing mixins
Marcel Reutegger created OAK-10334: -- Summary: Node.addMixin() may overwrite existing mixins Key: OAK-10334 URL: https://issues.apache.org/jira/browse/OAK-10334 Project: Jackrabbit Oak Issue Type: Bug Components: jcr Reporter: Marcel Reutegger A Session lacking permission to read property jcr:mixinTypes, but permission to write will overwrite existing mixins when calling Node.addMixin(). The implementation does not check if the session has permission to read jcr:mixinTypes and assumes there are no existing values when the session does not have permission. The result is a jcr:mixinTypes property with only a single value passed to addMixin(). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10313) Identify revisions created by late-write scenario
[ https://issues.apache.org/jira/browse/OAK-10313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved OAK-10313. Fix Version/s: 1.54.0 Resolution: Fixed Merged PR. > Identify revisions created by late-write scenario > - > > Key: OAK-10313 > URL: https://issues.apache.org/jira/browse/OAK-10313 > Project: Jackrabbit Oak > Issue Type: Task > Components: documentmk, run >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Fix For: 1.54.0 > > > OAK-10254 describes a 'late-write' scenario where a DocumentNodeStore is > writing some changes after its lease timed out. > Introduce a consistency check that identifies those revisions on a > NodeDocument. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10315) Counter for DocumentStore check
[ https://issues.apache.org/jira/browse/OAK-10315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved OAK-10315. Resolution: Fixed DocumentStoreCheckCommandTest was successful. Merged PR. > Counter for DocumentStore check > --- > > Key: OAK-10315 > URL: https://issues.apache.org/jira/browse/OAK-10315 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: run >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Fix For: 1.54.0 > > > Introduce a counter option for the documentstore-check command in oak-run. > The option should enable a processor that counts the number of documents and > nodes that exist. The ratio is useful to determine how many documents are > considered garbage. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10330) oak-it-osgi: temporarily introduce Guava dependency again
[
https://issues.apache.org/jira/browse/OAK-10330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger resolved OAK-10330.
Fix Version/s: 1.54.0
Resolution: Fixed
OSGiT tests look good now. Merged PR.
> oak-it-osgi: temporarily introduce Guava dependency again
> -
>
> Key: OAK-10330
> URL: https://issues.apache.org/jira/browse/OAK-10330
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: it
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
>Priority: Major
> Fix For: 1.54.0
>
>
> OAK-10218 removed Guava as a dependency, but with OAK-10307 original Guava is
> no more leaking through our Oak shaded version and now various tests in
> OsgiIT fail when executed in module oak-it-osgi.
> {noformat}
> [ERROR] Errors:
> [ERROR] OSGiIT.bundleStates » ClassNotFound
> org.apache.jackrabbit.oak.spi.state.NodeSt...
> [ERROR] OSGiIT.listBundles » ClassNotFound
> org.apache.jackrabbit.oak.spi.state.NodeSto...
> [ERROR] OSGiIT.listServices » ClassNotFound
> org.apache.jackrabbit.oak.spi.state.NodeSt...
> [ERROR] OSGiIT.testLeaseFailureHandlerIsExported » ClassNotFound
> org.apache.jackrabbit...
> [ERROR] OSGiIT.testNodeStore » ClassNotFound
> org.apache.jackrabbit.oak.spi.state.NodeS...
> [ERROR] OSGiIT.testRepository » ClassNotFound
> org.apache.jackrabbit.oak.spi.state.Node...
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-10330) oak-it-osgi: temporarily introduce Guava dependency again
[
https://issues.apache.org/jira/browse/OAK-10330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17737539#comment-17737539
]
Marcel Reutegger commented on OAK-10330:
Proposed fix: https://github.com/apache/jackrabbit-oak/pull/1009
> oak-it-osgi: temporarily introduce Guava dependency again
> -
>
> Key: OAK-10330
> URL: https://issues.apache.org/jira/browse/OAK-10330
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: it
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
>Priority: Major
>
> OAK-10218 removed Guava as a dependency, but with OAK-10307 original Guava is
> no more leaking through our Oak shaded version and now various tests in
> OsgiIT fail when executed in module oak-it-osgi.
> {noformat}
> [ERROR] Errors:
> [ERROR] OSGiIT.bundleStates » ClassNotFound
> org.apache.jackrabbit.oak.spi.state.NodeSt...
> [ERROR] OSGiIT.listBundles » ClassNotFound
> org.apache.jackrabbit.oak.spi.state.NodeSto...
> [ERROR] OSGiIT.listServices » ClassNotFound
> org.apache.jackrabbit.oak.spi.state.NodeSt...
> [ERROR] OSGiIT.testLeaseFailureHandlerIsExported » ClassNotFound
> org.apache.jackrabbit...
> [ERROR] OSGiIT.testNodeStore » ClassNotFound
> org.apache.jackrabbit.oak.spi.state.NodeS...
> [ERROR] OSGiIT.testRepository » ClassNotFound
> org.apache.jackrabbit.oak.spi.state.Node...
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (OAK-10330) oak-it-osgi: temporarily introduce Guava dependency again
Marcel Reutegger created OAK-10330:
--
Summary: oak-it-osgi: temporarily introduce Guava dependency again
Key: OAK-10330
URL: https://issues.apache.org/jira/browse/OAK-10330
Project: Jackrabbit Oak
Issue Type: Technical task
Components: it
Reporter: Marcel Reutegger
Assignee: Marcel Reutegger
OAK-10218 removed Guava as a dependency, but with OAK-10307 original Guava is
no more leaking through our Oak shaded version and now various tests in OsgiIT
fail when executed in module oak-it-osgi.
{noformat}
[ERROR] Errors:
[ERROR] OSGiIT.bundleStates » ClassNotFound
org.apache.jackrabbit.oak.spi.state.NodeSt...
[ERROR] OSGiIT.listBundles » ClassNotFound
org.apache.jackrabbit.oak.spi.state.NodeSto...
[ERROR] OSGiIT.listServices » ClassNotFound
org.apache.jackrabbit.oak.spi.state.NodeSt...
[ERROR] OSGiIT.testLeaseFailureHandlerIsExported » ClassNotFound
org.apache.jackrabbit...
[ERROR] OSGiIT.testNodeStore » ClassNotFound
org.apache.jackrabbit.oak.spi.state.NodeS...
[ERROR] OSGiIT.testRepository » ClassNotFound
org.apache.jackrabbit.oak.spi.state.Node...
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-10315) Counter for DocumentStore check
[ https://issues.apache.org/jira/browse/OAK-10315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17737536#comment-17737536 ] Marcel Reutegger commented on OAK-10315: Proposed fix: https://github.com/apache/jackrabbit-oak/pull/1008 > Counter for DocumentStore check > --- > > Key: OAK-10315 > URL: https://issues.apache.org/jira/browse/OAK-10315 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: run >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Fix For: 1.54.0 > > > Introduce a counter option for the documentstore-check command in oak-run. > The option should enable a processor that counts the number of documents and > nodes that exist. The ratio is useful to determine how many documents are > considered garbage. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (OAK-10315) Counter for DocumentStore check
[ https://issues.apache.org/jira/browse/OAK-10315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger reopened OAK-10315: Need to re-open. This change introduced test failures in oak-run. > Counter for DocumentStore check > --- > > Key: OAK-10315 > URL: https://issues.apache.org/jira/browse/OAK-10315 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: run >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Fix For: 1.54.0 > > > Introduce a counter option for the documentstore-check command in oak-run. > The option should enable a processor that counts the number of documents and > nodes that exist. The ratio is useful to determine how many documents are > considered garbage. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10315) Counter for DocumentStore check
[ https://issues.apache.org/jira/browse/OAK-10315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved OAK-10315. Fix Version/s: 1.54.0 Resolution: Fixed Merged the PR. > Counter for DocumentStore check > --- > > Key: OAK-10315 > URL: https://issues.apache.org/jira/browse/OAK-10315 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: run >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Fix For: 1.54.0 > > > Introduce a counter option for the documentstore-check command in oak-run. > The option should enable a processor that counts the number of documents and > nodes that exist. The ratio is useful to determine how many documents are > considered garbage. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-5782) Test failure: persistentCache.BroadcastTest.broadcastTCP
[ https://issues.apache.org/jira/browse/OAK-5782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved OAK-5782. --- Resolution: Cannot Reproduce Merged the PR that ignores the test. Resolving as cannot reproduce again. > Test failure: persistentCache.BroadcastTest.broadcastTCP > - > > Key: OAK-5782 > URL: https://issues.apache.org/jira/browse/OAK-5782 > Project: Jackrabbit Oak > Issue Type: Bug > Components: cache, continuous integration, core >Affects Versions: 1.6.0 >Reporter: Hudson >Assignee: Marcel Reutegger >Priority: Major > Labels: test-failure, ubuntu > > Jenkins CI failure: > https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/ > The build Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK 1.8 > (latest),nsfixtures=SEGMENT_TAR,profile=unittesting #1447 has failed. > First failed run: [Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK > 1.8 (latest),nsfixtures=SEGMENT_TAR,profile=unittesting > #1447|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.8%20(latest),nsfixtures=SEGMENT_TAR,profile=unittesting/1447/] > [console > log|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.8%20(latest),nsfixtures=SEGMENT_TAR,profile=unittesting/1447/console] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10321) Remove residual use of original Guava in oak-store-document
[
https://issues.apache.org/jira/browse/OAK-10321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736075#comment-17736075
]
Marcel Reutegger commented on OAK-10321:
OK, then let's keep these for now.
> Remove residual use of original Guava in oak-store-document
> ---
>
> Key: OAK-10321
> URL: https://issues.apache.org/jira/browse/OAK-10321
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: documentmk
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
>Priority: Minor
>
> Some code still uses original Guava classes.
> {noformat}
> [ERROR]
> /home/jenkins/jenkins-agent/workspace/Jackrabbit_oak-trunk-pr_PR-997/oak-store-document/src/main/java/org/apache/jackrabbit/oak/plugins/document/DocumentNodeStore.java:[1328,81]
> package com.google.common.util.concurrent does not exist
> [ERROR]
> /home/jenkins/jenkins-agent/workspace/Jackrabbit_oak-trunk-pr_PR-997/oak-store-document/src/main/java/org/apache/jackrabbit/oak/plugins/document/DocumentNodeStore.java:[1389,81]
> package com.google.common.util.concurrent does not exist
> [ERROR]
> /home/jenkins/jenkins-agent/workspace/Jackrabbit_oak-trunk-pr_PR-997/oak-store-document/src/main/java/org/apache/jackrabbit/oak/plugins/document/mongo/MongoDocumentStore.java:[631,81]
> package com.google.common.util.concurrent does not exist
> [ERROR]
> /home/jenkins/jenkins-agent/workspace/Jackrabbit_oak-trunk-pr_PR-997/oak-store-document/src/main/java/org/apache/jackrabbit/oak/plugins/document/mongo/MongoDocumentStore.java:[1777,81]
> package com.google.common.util.concurrent does not exist
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-10321) Remove residual use of original Guava in oak-store-document
[
https://issues.apache.org/jira/browse/OAK-10321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736055#comment-17736055
]
Marcel Reutegger commented on OAK-10321:
I don't think these are needed anymore.
{noformat}
diff --git
a/oak-store-document/src/main/java/org/apache/jackrabbit/oak/plugins/document/DocumentNodeStore.java
b/oak-store-document/src/main/java/org/apache/jackrabbit/oak/plugins/document/DocumentNodeStore.java
index 22b6244792..9c4cee90d0 100644
---
a/oak-store-document/src/main/java/org/apache/jackrabbit/oak/plugins/document/DocumentNodeStore.java
+++
b/oak-store-document/src/main/java/org/apache/jackrabbit/oak/plugins/document/DocumentNodeStore.java
@@ -1325,7 +1325,7 @@ public final class DocumentNodeStore
|| node.equals(missing) ? null : node;
PERFLOG.end(start, 1, "getNode: path={}, rev={}", path, rev);
return result;
-} catch (UncheckedExecutionException |
com.google.common.util.concurrent.UncheckedExecutionException e) {
+} catch (UncheckedExecutionException e) {
throw DocumentStoreException.convert(e.getCause());
} catch (ExecutionException e) {
throw DocumentStoreException.convert(e.getCause());
@@ -1386,7 +1386,7 @@ public final class DocumentNodeStore
nodeChildrenCache.put(key, children);
}
return children;
-} catch (UncheckedExecutionException |
com.google.common.util.concurrent.UncheckedExecutionException e) {
+} catch (UncheckedExecutionException e) {
throw DocumentStoreException.convert(e.getCause(),
"Error occurred while fetching children for path "
+ path);
diff --git
a/oak-store-document/src/main/java/org/apache/jackrabbit/oak/plugins/document/mongo/MongoDocumentStore.java
b/oak-store-document/src/main/java/org/apache/jackrabbit/oak/plugins/document/mongo/MongoDocumentStore.java
index 8b21976f30..1f156f4100 100644
---
a/oak-store-document/src/main/java/org/apache/jackrabbit/oak/plugins/document/mongo/MongoDocumentStore.java
+++
b/oak-store-document/src/main/java/org/apache/jackrabbit/oak/plugins/document/mongo/MongoDocumentStore.java
@@ -628,7 +628,7 @@ public class MongoDocumentStore implements DocumentStore {
} else {
return (T) doc;
}
-} catch (UncheckedExecutionException |
com.google.common.util.concurrent.UncheckedExecutionException e) {
+} catch (UncheckedExecutionException e) {
t = e.getCause();
} catch (ExecutionException e) {
t = e.getCause();
@@ -1774,7 +1774,7 @@ public class MongoDocumentStore implements DocumentStore {
}
}
return;
-} catch (UncheckedExecutionException |
com.google.common.util.concurrent.UncheckedExecutionException |
ExecutionException e) {
+} catch (UncheckedExecutionException | ExecutionException e) {
t = e.getCause();
} catch (RuntimeException e) {
t = e;
{noformat}
[~reschke], WDYT?
> Remove residual use of original Guava in oak-store-document
> ---
>
> Key: OAK-10321
> URL: https://issues.apache.org/jira/browse/OAK-10321
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: documentmk
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
>Priority: Minor
>
> Some code still uses original Guava classes.
> {noformat}
> [ERROR]
> /home/jenkins/jenkins-agent/workspace/Jackrabbit_oak-trunk-pr_PR-997/oak-store-document/src/main/java/org/apache/jackrabbit/oak/plugins/document/DocumentNodeStore.java:[1328,81]
> package com.google.common.util.concurrent does not exist
> [ERROR]
> /home/jenkins/jenkins-agent/workspace/Jackrabbit_oak-trunk-pr_PR-997/oak-store-document/src/main/java/org/apache/jackrabbit/oak/plugins/document/DocumentNodeStore.java:[1389,81]
> package com.google.common.util.concurrent does not exist
> [ERROR]
> /home/jenkins/jenkins-agent/workspace/Jackrabbit_oak-trunk-pr_PR-997/oak-store-document/src/main/java/org/apache/jackrabbit/oak/plugins/document/mongo/MongoDocumentStore.java:[631,81]
> package com.google.common.util.concurrent does not exist
> [ERROR]
> /home/jenkins/jenkins-agent/workspace/Jackrabbit_oak-trunk-pr_PR-997/oak-store-document/src/main/java/org/apache/jackrabbit/oak/plugins/document/mongo/MongoDocumentStore.java:[1777,81]
> package com.google.common.util.concurrent does not exist
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (OAK-10321) Remove residual use of original Guava in oak-store-document
Marcel Reutegger created OAK-10321:
--
Summary: Remove residual use of original Guava in
oak-store-document
Key: OAK-10321
URL: https://issues.apache.org/jira/browse/OAK-10321
Project: Jackrabbit Oak
Issue Type: Technical task
Components: documentmk
Reporter: Marcel Reutegger
Assignee: Marcel Reutegger
Some code still uses original Guava classes.
{noformat}
[ERROR]
/home/jenkins/jenkins-agent/workspace/Jackrabbit_oak-trunk-pr_PR-997/oak-store-document/src/main/java/org/apache/jackrabbit/oak/plugins/document/DocumentNodeStore.java:[1328,81]
package com.google.common.util.concurrent does not exist
[ERROR]
/home/jenkins/jenkins-agent/workspace/Jackrabbit_oak-trunk-pr_PR-997/oak-store-document/src/main/java/org/apache/jackrabbit/oak/plugins/document/DocumentNodeStore.java:[1389,81]
package com.google.common.util.concurrent does not exist
[ERROR]
/home/jenkins/jenkins-agent/workspace/Jackrabbit_oak-trunk-pr_PR-997/oak-store-document/src/main/java/org/apache/jackrabbit/oak/plugins/document/mongo/MongoDocumentStore.java:[631,81]
package com.google.common.util.concurrent does not exist
[ERROR]
/home/jenkins/jenkins-agent/workspace/Jackrabbit_oak-trunk-pr_PR-997/oak-store-document/src/main/java/org/apache/jackrabbit/oak/plugins/document/mongo/MongoDocumentStore.java:[1777,81]
package com.google.common.util.concurrent does not exist
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-5782) Test failure: persistentCache.BroadcastTest.broadcastTCP
[ https://issues.apache.org/jira/browse/OAK-5782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17735347#comment-17735347 ] Marcel Reutegger commented on OAK-5782: --- PR to ignore the test: https://github.com/apache/jackrabbit-oak/pull/997 > Test failure: persistentCache.BroadcastTest.broadcastTCP > - > > Key: OAK-5782 > URL: https://issues.apache.org/jira/browse/OAK-5782 > Project: Jackrabbit Oak > Issue Type: Bug > Components: cache, continuous integration, core >Affects Versions: 1.6.0 >Reporter: Hudson >Assignee: Marcel Reutegger >Priority: Major > Labels: test-failure, ubuntu > > Jenkins CI failure: > https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/ > The build Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK 1.8 > (latest),nsfixtures=SEGMENT_TAR,profile=unittesting #1447 has failed. > First failed run: [Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK > 1.8 (latest),nsfixtures=SEGMENT_TAR,profile=unittesting > #1447|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.8%20(latest),nsfixtures=SEGMENT_TAR,profile=unittesting/1447/] > [console > log|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.8%20(latest),nsfixtures=SEGMENT_TAR,profile=unittesting/1447/console] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (OAK-5782) Test failure: persistentCache.BroadcastTest.broadcastTCP
[
https://issues.apache.org/jira/browse/OAK-5782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger reopened OAK-5782:
---
Assignee: Marcel Reutegger (was: Thomas Mueller)
Still fails occasionally.
{noformat}
[ERROR]
broadcastTCP(org.apache.jackrabbit.oak.plugins.document.persistentCache.BroadcastTest)
Time elapsed: 10.125 s <<< FAILURE! java.lang.AssertionError: expected null,
but was:
at org.junit.Assert.fail(Assert.java:89)
at org.junit.Assert.failNotNull(Assert.java:756)
at org.junit.Assert.assertNull(Assert.java:738)
at org.junit.Assert.assertNull(Assert.java:748)
at
org.apache.jackrabbit.oak.plugins.document.persistentCache.BroadcastTest.broadcastTry(BroadcastTest.java:223)
at
org.apache.jackrabbit.oak.plugins.document.persistentCache.BroadcastTest.broadcast(BroadcastTest.java:196)
at
org.apache.jackrabbit.oak.plugins.document.persistentCache.BroadcastTest.broadcastTCP(BroadcastTest.java:147)
{noformat}
> Test failure: persistentCache.BroadcastTest.broadcastTCP
> -
>
> Key: OAK-5782
> URL: https://issues.apache.org/jira/browse/OAK-5782
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: cache, continuous integration, core
>Affects Versions: 1.6.0
>Reporter: Hudson
>Assignee: Marcel Reutegger
>Priority: Major
> Labels: test-failure, ubuntu
>
> Jenkins CI failure:
> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/
> The build Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK 1.8
> (latest),nsfixtures=SEGMENT_TAR,profile=unittesting #1447 has failed.
> First failed run: [Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK
> 1.8 (latest),nsfixtures=SEGMENT_TAR,profile=unittesting
> #1447|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.8%20(latest),nsfixtures=SEGMENT_TAR,profile=unittesting/1447/]
> [console
> log|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.8%20(latest),nsfixtures=SEGMENT_TAR,profile=unittesting/1447/console]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-10315) Counter for DocumentStore check
[ https://issues.apache.org/jira/browse/OAK-10315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17735336#comment-17735336 ] Marcel Reutegger commented on OAK-10315: Proposed implementation: https://github.com/apache/jackrabbit-oak/pull/996 > Counter for DocumentStore check > --- > > Key: OAK-10315 > URL: https://issues.apache.org/jira/browse/OAK-10315 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: run >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > > Introduce a counter option for the documentstore-check command in oak-run. > The option should enable a processor that counts the number of documents and > nodes that exist. The ratio is useful to determine how many documents are > considered garbage. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10315) Counter for DocumentStore check
Marcel Reutegger created OAK-10315: -- Summary: Counter for DocumentStore check Key: OAK-10315 URL: https://issues.apache.org/jira/browse/OAK-10315 Project: Jackrabbit Oak Issue Type: Improvement Components: run Reporter: Marcel Reutegger Assignee: Marcel Reutegger Introduce a counter option for the documentstore-check command in oak-run. The option should enable a processor that counts the number of documents and nodes that exist. The ratio is useful to determine how many documents are considered garbage. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10313) Identify revisions created by late-write scenario
[ https://issues.apache.org/jira/browse/OAK-10313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17734218#comment-17734218 ] Marcel Reutegger commented on OAK-10313: Created new tests in WriteAfterRecoveryTest similar to those in OAK-10254, but using the existing FailingDocumentStore (with some enhancements) to simulate 'late-write' scenarios for various content changes. The consistency check takes a root node state and a NodeDocument and identifies change revisions that are not visible when traversing to the node state represented by the given NodeDocument even though they should be given the head revision on the root node state. Proposed changed in https://github.com/apache/jackrabbit-oak/pull/995 > Identify revisions created by late-write scenario > - > > Key: OAK-10313 > URL: https://issues.apache.org/jira/browse/OAK-10313 > Project: Jackrabbit Oak > Issue Type: Task > Components: documentmk, run >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > > OAK-10254 describes a 'late-write' scenario where a DocumentNodeStore is > writing some changes after its lease timed out. > Introduce a consistency check that identifies those revisions on a > NodeDocument. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10313) Identify revisions created by late-write scenario
Marcel Reutegger created OAK-10313: -- Summary: Identify revisions created by late-write scenario Key: OAK-10313 URL: https://issues.apache.org/jira/browse/OAK-10313 Project: Jackrabbit Oak Issue Type: Task Components: documentmk, run Reporter: Marcel Reutegger Assignee: Marcel Reutegger OAK-10254 describes a 'late-write' scenario where a DocumentNodeStore is writing some changes after its lease timed out. Introduce a consistency check that identifies those revisions on a NodeDocument. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10308) Tests using MongoUtils may skip even if Docker is available
[ https://issues.apache.org/jira/browse/OAK-10308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved OAK-10308. Fix Version/s: 1.54.0 Resolution: Fixed Merged PR. > Tests using MongoUtils may skip even if Docker is available > --- > > Key: OAK-10308 > URL: https://issues.apache.org/jira/browse/OAK-10308 > Project: Jackrabbit Oak > Issue Type: Bug > Components: documentmk, mongomk >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Fix For: 1.54.0 > > > MongoUtil first tries to connect to an already running MongoDB on the default > port and then tries to start MongoDB in docker. The latter may fail even when > docker is available and MongoDB is started successfully. > The host for the constructed connection URI is hardcoded to 'localhost', > which may not work when docker exposed MongoDB on 127.0.0.1: -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10308) Tests using MongoUtils may skip even if Docker is available
[ https://issues.apache.org/jira/browse/OAK-10308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17733136#comment-17733136 ] Marcel Reutegger commented on OAK-10308: Proposed changes: https://github.com/apache/jackrabbit-oak/pull/990 > Tests using MongoUtils may skip even if Docker is available > --- > > Key: OAK-10308 > URL: https://issues.apache.org/jira/browse/OAK-10308 > Project: Jackrabbit Oak > Issue Type: Bug > Components: documentmk, mongomk >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > > MongoUtil first tries to connect to an already running MongoDB on the default > port and then tries to start MongoDB in docker. The latter may fail even when > docker is available and MongoDB is started successfully. > The host for the constructed connection URI is hardcoded to 'localhost', > which may not work when docker exposed MongoDB on 127.0.0.1: -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10308) Tests using MongoUtils may skip even if Docker is available
Marcel Reutegger created OAK-10308: -- Summary: Tests using MongoUtils may skip even if Docker is available Key: OAK-10308 URL: https://issues.apache.org/jira/browse/OAK-10308 Project: Jackrabbit Oak Issue Type: Bug Components: documentmk, mongomk Reporter: Marcel Reutegger Assignee: Marcel Reutegger MongoUtil first tries to connect to an already running MongoDB on the default port and then tries to start MongoDB in docker. The latter may fail even when docker is available and MongoDB is started successfully. The host for the constructed connection URI is hardcoded to 'localhost', which may not work when docker exposed MongoDB on 127.0.0.1: -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10306) Incorrect dependency scope for commons-math3
[ https://issues.apache.org/jira/browse/OAK-10306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved OAK-10306. Fix Version/s: 1.54.0 Resolution: Fixed Merged PR. > Incorrect dependency scope for commons-math3 > > > Key: OAK-10306 > URL: https://issues.apache.org/jira/browse/OAK-10306 > Project: Jackrabbit Oak > Issue Type: Bug > Components: commons >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Fix For: 1.54.0 > > > The dependency commons-math3 is only used for tests in oak-commons, but is > currently set to compile and optional. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10288) mvn test for oak-commons fails in top level directory, but not in project directory
[
https://issues.apache.org/jira/browse/OAK-10288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17733049#comment-17733049
]
Marcel Reutegger commented on OAK-10288:
Created OAK-10307 for the transitive dependency issue with oak-shaded-guava.
> mvn test for oak-commons fails in top level directory, but not in project
> directory
> ---
>
> Key: OAK-10288
> URL: https://issues.apache.org/jira/browse/OAK-10288
> Project: Jackrabbit Oak
> Issue Type: Test
> Components: commons
>Reporter: Manfred Baedke
>Priority: Minor
>
> While
> {code:java}
> mvn clean install{code}
> is running fine,
> {code:java}
> mvn test{code}
> is failing due to
> {code:java}
> java.lang.ClassNotFoundException:
> org.apache.jackrabbit.guava.common.collect.Sets{code}
> , but only when run in the top level directory. It will succeed when run in
> the oak-commons project directory.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (OAK-10307) oak-shaded-guava leaks original guava as transitive dependency
Marcel Reutegger created OAK-10307:
--
Summary: oak-shaded-guava leaks original guava as transitive
dependency
Key: OAK-10307
URL: https://issues.apache.org/jira/browse/OAK-10307
Project: Jackrabbit Oak
Issue Type: Technical task
Components: shaded-guava
Reporter: Marcel Reutegger
oak-shaded-guava currently declares a compile dependency on original guava.
This means modules using oak-shaded-guava will transitively get original guava
and mistakingly use classes from there.
{noformat}
$ mvn dependency:tree -pl :oak-shaded-guava
[INFO] Scanning for projects...
[INFO]
[INFO] ---< org.apache.jackrabbit:oak-shaded-guava >---
[INFO] Building Jackrabbit Guava Wrapper 1.53-SNAPSHOT
[INFO] from pom.xml
[INFO] ---[ bundle ]---
[INFO]
[INFO] --- dependency:3.4.0:tree (default-cli) @ oak-shaded-guava ---
[INFO] org.apache.jackrabbit:oak-shaded-guava:bundle:1.53-SNAPSHOT
[INFO] +- com.google.guava:guava:jar:32.0.1-jre:compile
[INFO] | +- com.google.guava:failureaccess:jar:1.0.1:compile
[INFO] | +-
com.google.guava:listenablefuture:jar:.0-empty-to-avoid-conflict-with-guava:compile
[INFO] | +- com.google.code.findbugs:jsr305:jar:3.0.2:compile
[INFO] | +- org.checkerframework:checker-qual:jar:3.33.0:compile
[INFO] | +- com.google.errorprone:error_prone_annotations:jar:2.18.0:compile
[INFO] | \- com.google.j2objc:j2objc-annotations:jar:2.8:compile
[INFO] +- org.osgi:org.osgi.annotation:jar:6.0.0:provided
[INFO] \- org.jetbrains:annotations:jar:18.0.0:provided
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-10247) oak-commons: remove Guava from public API
[ https://issues.apache.org/jira/browse/OAK-10247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17733036#comment-17733036 ] Marcel Reutegger commented on OAK-10247: This looks incomplete to me. There are still usages of Guava 15 in oak-commons. E.g. https://github.com/apache/jackrabbit-oak/blob/trunk/oak-commons/src/main/java/org/apache/jackrabbit/oak/commons/FileIOUtils.java#L73 The problem is oak-shaded-guava which silently introduced Guava 15 again as transitive dependency. See also [comment|https://issues.apache.org/jira/browse/OAK-10288?focusedCommentId=17733026&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17733026] in OAK-10288. > oak-commons: remove Guava from public API > - > > Key: OAK-10247 > URL: https://issues.apache.org/jira/browse/OAK-10247 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: commons >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Major > Fix For: 1.54.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10306) Incorrect dependency scope for commons-math3
[ https://issues.apache.org/jira/browse/OAK-10306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17733035#comment-17733035 ] Marcel Reutegger commented on OAK-10306: Proposed changes: https://github.com/apache/jackrabbit-oak/pull/985 > Incorrect dependency scope for commons-math3 > > > Key: OAK-10306 > URL: https://issues.apache.org/jira/browse/OAK-10306 > Project: Jackrabbit Oak > Issue Type: Bug > Components: commons >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > > The dependency commons-math3 is only used for tests in oak-commons, but is > currently set to compile and optional. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10288) mvn test for oak-commons fails in top level directory, but not in project directory
[
https://issues.apache.org/jira/browse/OAK-10288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17733026#comment-17733026
]
Marcel Reutegger commented on OAK-10288:
It doesn't really explain the different behaviour, but oak-commons still has an
undeclared dependency to Guava 15.
{noformat}
mvn dependency:analyze -pl :oak-commons
{noformat}
says:
{noformat}
[INFO] --- dependency:3.4.0:analyze (default-cli) @ oak-commons ---
[WARNING] Used undeclared dependencies found:
[WARNING]ch.qos.logback:logback-core:jar:1.2.10:test
[WARNING]org.hamcrest:hamcrest-core:jar:1.3:test
[WARNING]com.google.guava:guava:jar:15.0:compile
{noformat}
Hmm, it is a transitive dependency through oak-shaded-guava.
{noformat}
$ mvn dependency:tree -pl :oak-commons
[INFO] Scanning for projects...
[INFO]
[INFO] -< org.apache.jackrabbit:oak-commons >--
[INFO] Building Oak Commons 1.53-SNAPSHOT
[INFO] from pom.xml
[INFO] ---[ bundle ]---
[INFO]
[INFO] --- dependency:3.4.0:tree (default-cli) @ oak-commons ---
[INFO] org.apache.jackrabbit:oak-commons:bundle:1.53-SNAPSHOT
[INFO] +- org.osgi:org.osgi.annotation:jar:6.0.0:provided
[INFO] +- org.slf4j:slf4j-api:jar:1.7.36:compile
[INFO] +- org.jetbrains:annotations:jar:18.0.0:provided
[INFO] +- commons-io:commons-io:jar:2.11.0:compile
[INFO] +- org.apache.jackrabbit:jackrabbit-jcr-commons:jar:2.20.10:compile
[INFO] +- org.apache.jackrabbit:oak-shaded-guava:jar:1.53-SNAPSHOT:compile
[INFO] | \- com.google.guava:guava:jar:15.0:compile
[INFO] +- junit:junit:jar:4.13.1:test
[INFO] | \- org.hamcrest:hamcrest-core:jar:1.3:test
[INFO] +- ch.qos.logback:logback-classic:jar:1.2.10:test
[INFO] | \- ch.qos.logback:logback-core:jar:1.2.10:test
[INFO] +- org.apache.commons:commons-math3:jar:3.6.1:test
[INFO] +- org.apache.commons:commons-lang3:jar:3.12.0:test
[INFO] +- org.mockito:mockito-core:jar:4.11.0:test
[INFO] | +- net.bytebuddy:byte-buddy:jar:1.12.19:test
[INFO] | +- net.bytebuddy:byte-buddy-agent:jar:1.12.19:test
[INFO] | \- org.objenesis:objenesis:jar:3.3:test
[INFO] \- org.lz4:lz4-java:jar:1.8.0:test
{noformat}
Wouldn't it be better if oak-shaded-guava doesn't leak native guava 15?
> mvn test for oak-commons fails in top level directory, but not in project
> directory
> ---
>
> Key: OAK-10288
> URL: https://issues.apache.org/jira/browse/OAK-10288
> Project: Jackrabbit Oak
> Issue Type: Test
> Components: commons
>Reporter: Manfred Baedke
>Priority: Minor
>
> While
> {code:java}
> mvn clean install{code}
> is running fine,
> {code:java}
> mvn test{code}
> is failing due to
> {code:java}
> java.lang.ClassNotFoundException:
> org.apache.jackrabbit.guava.common.collect.Sets{code}
> , but only when run in the top level directory. It will succeed when run in
> the oak-commons project directory.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (OAK-10306) Incorrect dependency scope for commons-math3
Marcel Reutegger created OAK-10306: -- Summary: Incorrect dependency scope for commons-math3 Key: OAK-10306 URL: https://issues.apache.org/jira/browse/OAK-10306 Project: Jackrabbit Oak Issue Type: Bug Components: commons Reporter: Marcel Reutegger Assignee: Marcel Reutegger The dependency commons-math3 is only used for tests in oak-commons, but is currently set to compile and optional. -- This message was sent by Atlassian Jira (v8.20.10#820010)
