[jira] [Comment Edited] (OAK-4344) LdapIdentityProvider always retrieves all attributes when looking up an LDAP entity.
[ https://issues.apache.org/jira/browse/OAK-4344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15371418#comment-15371418 ] Manfred Baedke edited comment on OAK-4344 at 7/11/16 7:15 PM: -- Fixed in trunk: revs 1752198, 1752202. was (Author: baedke): Fixed in trunk: r1752198 > LdapIdentityProvider always retrieves all attributes when looking up an LDAP > entity. > > > Key: OAK-4344 > URL: https://issues.apache.org/jira/browse/OAK-4344 > Project: Jackrabbit Oak > Issue Type: Improvement >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Minor > Fix For: 1.6 > > > Retrieving all attributes is usually unnecessary and may be costly. The > current behavior should be the default, but it should also be possible to > configure an explicit list of attributes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-4344) LdapIdentityProvider always retrieves all attributes when looking up an LDAP entity.
[ https://issues.apache.org/jira/browse/OAK-4344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke resolved OAK-4344. - Resolution: Fixed Fix Version/s: 1.6 > LdapIdentityProvider always retrieves all attributes when looking up an LDAP > entity. > > > Key: OAK-4344 > URL: https://issues.apache.org/jira/browse/OAK-4344 > Project: Jackrabbit Oak > Issue Type: Improvement >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Minor > Fix For: 1.6 > > > Retrieving all attributes is usually unnecessary and may be costly. The > current behavior should be the default, but it should also be possible to > configure an explicit list of attributes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-4344) LdapIdentityProvider always retrieves all attributes when looking up an LDAP entity.
[ https://issues.apache.org/jira/browse/OAK-4344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15371418#comment-15371418 ] Manfred Baedke commented on OAK-4344: - Fixed in trunk: r1752198 > LdapIdentityProvider always retrieves all attributes when looking up an LDAP > entity. > > > Key: OAK-4344 > URL: https://issues.apache.org/jira/browse/OAK-4344 > Project: Jackrabbit Oak > Issue Type: Improvement >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Minor > > Retrieving all attributes is usually unnecessary and may be costly. The > current behavior should be the default, but it should also be possible to > configure an explicit list of attributes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-4201) Add an index of binary references in a tar file
[
https://issues.apache.org/jira/browse/OAK-4201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Mari resolved OAK-4201.
-
Resolution: Fixed
Fixed in r1752166.
> Add an index of binary references in a tar file
> ---
>
> Key: OAK-4201
> URL: https://issues.apache.org/jira/browse/OAK-4201
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Reporter: Chetan Mehrotra
>Assignee: Francesco Mari
> Fix For: Segment Tar 0.0.4
>
> Attachments: OAK-4201-01.patch
>
>
> Currently for Blob GC in case of segment {{SegmentBlobReferenceRetriever}}
> goes through all tar files and extracts the binary references. This has 2
> issues
> # Logic has go through all the segments in all tar files
> # All segments get loaded in memory once which would affect normal system
> performance
> This process can be optimized if we also write a file entry in tar (similar
> to gph i.e. graph and idx i.e. index files) which has entries of all binary
> references referred to in any segment present in that tar file. Then GC logic
> would just have read this file and avoid scanning all the segments
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-4550) make Jackrabbit dependencies consistent
[ https://issues.apache.org/jira/browse/OAK-4550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke resolved OAK-4550. - Resolution: Won't Fix We are currently using a mix, and 2.13.0-SNAPSHOT is only used in selected places. Thus we can wait for Jackrabbit 2.13.1. > make Jackrabbit dependencies consistent > --- > > Key: OAK-4550 > URL: https://issues.apache.org/jira/browse/OAK-4550 > Project: Jackrabbit Oak > Issue Type: Task >Affects Versions: 1.5.5 >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > > We are currently referencing different versions throughout; make those > consistent and switch to 2.13.1-SNAPSHOT for now. > (One 2.13.1 with the fix for JCR-3992 is out, switch to that version) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-4551) Update Oak to Jackrabbit 2.13.1
Julian Reschke created OAK-4551: --- Summary: Update Oak to Jackrabbit 2.13.1 Key: OAK-4551 URL: https://issues.apache.org/jira/browse/OAK-4551 Project: Jackrabbit Oak Issue Type: Task Reporter: Julian Reschke Assignee: Julian Reschke Priority: Minor -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-4550) make Jackrabbit dependencies consistent
Julian Reschke created OAK-4550: --- Summary: make Jackrabbit dependencies consistent Key: OAK-4550 URL: https://issues.apache.org/jira/browse/OAK-4550 Project: Jackrabbit Oak Issue Type: Task Affects Versions: 1.5.5 Reporter: Julian Reschke Assignee: Julian Reschke Priority: Minor We are currently referencing different versions throughout; make those consistent and switch to 2.13.1-SNAPSHOT for now. (One 2.13.1 with the fix for JCR-3992 is out, switch to that version) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-4201) Add an index of binary references in a tar file
[
https://issues.apache.org/jira/browse/OAK-4201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15370894#comment-15370894
]
Alex Parvulescu commented on OAK-4201:
--
Looks good to me +1
> Add an index of binary references in a tar file
> ---
>
> Key: OAK-4201
> URL: https://issues.apache.org/jira/browse/OAK-4201
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Reporter: Chetan Mehrotra
>Assignee: Francesco Mari
> Fix For: Segment Tar 0.0.4
>
> Attachments: OAK-4201-01.patch
>
>
> Currently for Blob GC in case of segment {{SegmentBlobReferenceRetriever}}
> goes through all tar files and extracts the binary references. This has 2
> issues
> # Logic has go through all the segments in all tar files
> # All segments get loaded in memory once which would affect normal system
> performance
> This process can be optimized if we also write a file entry in tar (similar
> to gph i.e. graph and idx i.e. index files) which has entries of all binary
> references referred to in any segment present in that tar file. Then GC logic
> would just have read this file and avoid scanning all the segments
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-3309) Segment Tar SegmentCache loader stats
[ https://issues.apache.org/jira/browse/OAK-3309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Parvulescu resolved OAK-3309. -- Resolution: Fixed the bulk of the work was already done (all segment loading already goes through a loader), I added some tests, and fixed a typo in a method name, removed an unused method. fixed in trunk with http://svn.apache.org/viewvc?rev=1752160&view=rev > Segment Tar SegmentCache loader stats > - > > Key: OAK-3309 > URL: https://issues.apache.org/jira/browse/OAK-3309 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: segment-tar >Reporter: Alex Parvulescu >Assignee: Alex Parvulescu > Labels: gc > Fix For: 1.6, Segment Tar 0.0.4 > > Attachments: OAK-3309.patch > > > The existing Segment Cache has no loading-related stats, I'd like to see how > complicated it would be to add some. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3309) Segment Tar SegmentCache loader stats
[ https://issues.apache.org/jira/browse/OAK-3309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Parvulescu updated OAK-3309: - Summary: Segment Tar SegmentCache loader stats (was: SegmentMK segment cache loader stats) > Segment Tar SegmentCache loader stats > - > > Key: OAK-3309 > URL: https://issues.apache.org/jira/browse/OAK-3309 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: segment-tar >Reporter: Alex Parvulescu >Assignee: Alex Parvulescu > Labels: gc > Fix For: 1.6, Segment Tar 0.0.4 > > Attachments: OAK-3309.patch > > > The existing Segment Cache has no loading-related stats, I'd like to see how > complicated it would be to add some. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-4541) Update Oak to Jackrabbit 2.13.0
[ https://issues.apache.org/jira/browse/OAK-4541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke resolved OAK-4541. - Resolution: Won't Fix As 2.13.0 is broken; see JCR-3992. > Update Oak to Jackrabbit 2.13.0 > --- > > Key: OAK-4541 > URL: https://issues.apache.org/jira/browse/OAK-4541 > Project: Jackrabbit Oak > Issue Type: Task >Affects Versions: 1.5.5 >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Fix For: 1.6 > > Attachments: OAK-4541.diff > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-4541) Update Oak to Jackrabbit 2.13.0
[ https://issues.apache.org/jira/browse/OAK-4541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15370709#comment-15370709 ] Julian Reschke commented on OAK-4541: - And the reason is the new bug described in JCR-3992 > Update Oak to Jackrabbit 2.13.0 > --- > > Key: OAK-4541 > URL: https://issues.apache.org/jira/browse/OAK-4541 > Project: Jackrabbit Oak > Issue Type: Task >Affects Versions: 1.5.5 >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Fix For: 1.6 > > Attachments: OAK-4541.diff > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4532) race-condition in commit-rate-limiter
[
https://issues.apache.org/jira/browse/OAK-4532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Egli updated OAK-4532:
-
Fix Version/s: (was: 1.5.5)
1.5.6
> race-condition in commit-rate-limiter
> -
>
> Key: OAK-4532
> URL: https://issues.apache.org/jira/browse/OAK-4532
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.5.4
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: 1.5.6
>
>
> [CommitRateLimiter.delay|https://github.com/apache/jackrabbit-oak/blob/jackrabbit-oak-1.5.4/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/observation/CommitRateLimiter.java#L81]
> has a race-condition when the queue length drops below thres-hold right when
> {{delay()}} is called. Consider the following steps:
> * thread T1 enters {{delay()}} with a positive value for {{delay}} but gets
> paused right after the check for {{delay>0}}
> * thread T2 enters {{setDelay(0)}}, thus goes into the synchronized block and
> does a notifyAll
> * thread T1 continues in {{delay()}} after above mentioned check, thus now
> goes into the synchronized block - at this stage {{delay}} is {{0}} (as it's
> volatile) - thus it sets {{dt=0}}.
> * thread T1 then goes and calls {{wait(0)}} - which is an infinite wait,
> until it gets notified. This can be forever if the threshold is never ever
> hit again.
> Would suggest to do a {{while}} loop rather than a {{do-while}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4534) add trace logging to CommitRateLimiter
[
https://issues.apache.org/jira/browse/OAK-4534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Egli updated OAK-4534:
-
Fix Version/s: (was: 1.5.5)
1.5.6
> add trace logging to CommitRateLimiter
> --
>
> Key: OAK-4534
> URL: https://issues.apache.org/jira/browse/OAK-4534
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.5.4
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: 1.5.6
>
>
> When debugging issues around CommitRateLimiter it would be useful to have
> more insight about what delays are actually applied. As that's rather noisy
> info {{log.trace}} is probably appropriate.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4533) make DELAY_THRESHOLD & MAX_DELAY of ChangeProcessor configurable
[ https://issues.apache.org/jira/browse/OAK-4533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Egli updated OAK-4533: - Fix Version/s: (was: 1.5.5) 1.5.6 > make DELAY_THRESHOLD & MAX_DELAY of ChangeProcessor configurable > > > Key: OAK-4533 > URL: https://issues.apache.org/jira/browse/OAK-4533 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: jcr >Affects Versions: 1.5.4 >Reporter: Stefan Egli >Assignee: Stefan Egli > Fix For: 1.5.6 > > > Currently DELAY_THRESHOLD & MAX_DELAY of ChangeProcessor are hardcoded at 0.8 > / 1. While we should come up with good defaults it might make sense to > have these values configurable too. The most simplistic could be via a > System.property for example. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (OAK-4490) Expose SegmentNodeStore as a secondary NodeStore
[ https://issues.apache.org/jira/browse/OAK-4490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominique Jäggi closed OAK-4490. bulk close after 1.5.5 release > Expose SegmentNodeStore as a secondary NodeStore > > > Key: OAK-4490 > URL: https://issues.apache.org/jira/browse/OAK-4490 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: segment-tar, segmentmk >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra >Priority: Minor > Fix For: 1.6, 1.5.5, Segment Tar 0.0.4 > > Attachments: OAK-4490-v1.patch > > > For OAK-4180 to work we would need to configure a SegmentNodeStore as a > secondary NodeStore. This NodeStore instance is used as a local cache of > remote content for certain paths. > Point to note > # The NodeStore instance would be full functional except it would not be > registering any Observor > # With this its possible to have a setup where multiple NodeStore instances > are registered in same service registry. So it needs to be ensure that any > other component which depends on NodeStore binds to correct store -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (OAK-4510) RDBDocumentStore: can't persist _modified value of null
[
https://issues.apache.org/jira/browse/OAK-4510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dominique Jäggi closed OAK-4510.
bulk close after 1.5.5 release
> RDBDocumentStore: can't persist _modified value of null
> ---
>
> Key: OAK-4510
> URL: https://issues.apache.org/jira/browse/OAK-4510
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: documentmk, rdbmk
>Affects Versions: 1.0.31, 1.2.16, 1.5.4, 1.4.4
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Fix For: 1.6, 1.0.32, 1.2.17, 1.5.5, 1.4.5
>
>
> This is tested in {{BasicDocumentStoreTest.testUpdateModified}}, but that
> test uses {{Collection.NODES}}, and the invalidation logic in
> {{RDBDocumentStore}} causes the cached value to be re-used because the
> {{modcount}} matches.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (OAK-2819) Persistent cache: tool to dump the contents
[ https://issues.apache.org/jira/browse/OAK-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominique Jäggi closed OAK-2819. bulk close after 1.5.5 release > Persistent cache: tool to dump the contents > --- > > Key: OAK-2819 > URL: https://issues.apache.org/jira/browse/OAK-2819 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Reporter: Thomas Mueller >Assignee: Thomas Mueller > Fix For: 1.5.5 > > Attachments: DumpCache.java > > > To analyze a system, it would be good to have a tool that can dump (a portion > of) the persistent cache. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (OAK-4475) CI failing on branches due to unknown fixture SEGMENT_TAR
[
https://issues.apache.org/jira/browse/OAK-4475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dominique Jäggi closed OAK-4475.
bulk close after 1.5.5 release
> CI failing on branches due to unknown fixture SEGMENT_TAR
> -
>
> Key: OAK-4475
> URL: https://issues.apache.org/jira/browse/OAK-4475
> Project: Jackrabbit Oak
> Issue Type: Bug
>Reporter: Michael Dürig
>Assignee: Chetan Mehrotra
> Labels: CI, build, jenkins
> Fix For: 1.6, 1.5.5
>
> Attachments: OAK-4475-v1.patch
>
>
> These failures are caused by adding the SEGMENT_TAR fixture to the matrix.
> That one doesn't exit in the branches thus the {{IllegalArgumentException}}
> "No enum constant".
> See discussion http://markmail.org/message/oaptnvco5y2a4rjk
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (OAK-4514) ResurrectNodeAfterRevisionGCTest's cleanup may interfere with DS disposal
[
https://issues.apache.org/jira/browse/OAK-4514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dominique Jäggi closed OAK-4514.
bulk close after 1.5.5 release
> ResurrectNodeAfterRevisionGCTest's cleanup may interfere with DS disposal
> -
>
> Key: OAK-4514
> URL: https://issues.apache.org/jira/browse/OAK-4514
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: documentmk
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Fix For: 1.6, 1.0.32, 1.2.17, 1.5.5, 1.4.5
>
> Attachments: OAK-4514.patch
>
>
> {{AbstractDocumentStore}} current calls {{dispose}} on {{DocumentStore}}
> instances when cleaning up.
> This interferes with {{ResurrectNodeAfterRevisionGCTest}} which creates node
> store instances on top of the document stores, and calls {{dispose()}} on
> them, leading to multiple calls to {{dispose}} on the same instance.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (OAK-4454) Create consistent API in ExternalSort to write and read escaped line breaks
[
https://issues.apache.org/jira/browse/OAK-4454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dominique Jäggi closed OAK-4454.
bulk close after 1.5.5 release
> Create consistent API in ExternalSort to write and read escaped line breaks
> ---
>
> Key: OAK-4454
> URL: https://issues.apache.org/jira/browse/OAK-4454
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: commons
>Reporter: Amit Jain
>Assignee: Amit Jain
>Priority: Minor
> Labels: candidate_oak_1_4
> Fix For: 1.5.5
>
>
> ExternalSort while sorting uses {{EscapeUtils.unescapeLineBreaks}} to read
> lines. It is better if a new API is created with explicit expectations
> documented that the File being sorted has been properly escaped with
> {{EscapeUtils.escapeLineBreak}}.
> Otherwise, it will lead to situations like OAK-4441 where File is not escaped
> while writing.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (OAK-4494) Stale documents after revision GC in cluster
[ https://issues.apache.org/jira/browse/OAK-4494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominique Jäggi closed OAK-4494. bulk close after 1.5.5 release > Stale documents after revision GC in cluster > > > Key: OAK-4494 > URL: https://issues.apache.org/jira/browse/OAK-4494 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core, documentmk, mongomk, rdbmk >Reporter: Marcel Reutegger >Assignee: Julian Reschke >Priority: Minor > Fix For: 1.6, 1.0.32, 1.2.17, 1.5.5, 1.4.5 > > Attachments: OAK-4494-RDB-1.4.diff, OAK-4494-RDB.diff, > OAK-4494.patch, OAK-4494.patch > > > Implement additional tests for revision GC in a cluster. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (OAK-4516) Configurable option to lucene index defs to index original (unanalyzed value as well)
[
https://issues.apache.org/jira/browse/OAK-4516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dominique Jäggi closed OAK-4516.
bulk close after 1.5.5 release
> Configurable option to lucene index defs to index original (unanalyzed value
> as well)
> -
>
> Key: OAK-4516
> URL: https://issues.apache.org/jira/browse/OAK-4516
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Minor
> Fix For: 1.6, 1.5.5
>
> Attachments: OAK-4516.patch
>
>
> It's sometimes useful to have original value being indexed to be stored as a
> term. One use-case could be like:
> * consider a couple of values to be indexed as {{abc_def}}, {{abcdef}}
> * On query, it seems reasonable to get both values for a query for {{abc*}}
> * On query, at times, it might be useful to expect {{abc_def}} for
> {{abc_d\*}} or {{abc_\*}}
> Currently, the values would get indexed like:
> * {{abc_def}} -> {{\[abc], \[def]}}
> * {{abcdef}} -> {{\[abcdef]}}
> So, the query {{abc*}} would only fetch {{abcdef}}, while {{abc_d\*}} or
> {{abc_\*}} won't fetch anything.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (OAK-4534) add trace logging to CommitRateLimiter
[
https://issues.apache.org/jira/browse/OAK-4534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dominique Jäggi closed OAK-4534.
bulk close after 1.5.5 release
> add trace logging to CommitRateLimiter
> --
>
> Key: OAK-4534
> URL: https://issues.apache.org/jira/browse/OAK-4534
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.5.4
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: 1.5.5
>
>
> When debugging issues around CommitRateLimiter it would be useful to have
> more insight about what delays are actually applied. As that's rather noisy
> info {{log.trace}} is probably appropriate.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (OAK-4523) Query: first selector should be main selector
[
https://issues.apache.org/jira/browse/OAK-4523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dominique Jäggi closed OAK-4523.
bulk close after 1.5.5 release
> Query: first selector should be main selector
> -
>
> Key: OAK-4523
> URL: https://issues.apache.org/jira/browse/OAK-4523
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: query
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
> Fix For: 1.5.5
>
>
> Some applications and tools expect that the first selector is the "main"
> selector. This is not a bug (violation of the JCR spec or contrary to the
> documentation) but a compatibility issue with Jackrabbit 2.x. So for the
> XPath query
> {noformat}
> //a[@x]/b[@y]
> {noformat}
> the expectation is that the path of the first selector is "/a/b" and not
> "/a". The XPath query is converted to SQL-2 join, that has two selectors.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (OAK-4476) Option to check datastore consistency in oak-run
[ https://issues.apache.org/jira/browse/OAK-4476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominique Jäggi closed OAK-4476. bulk close after 1.5.5 release > Option to check datastore consistency in oak-run > > > Key: OAK-4476 > URL: https://issues.apache.org/jira/browse/OAK-4476 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: run >Reporter: Amit Jain >Assignee: Amit Jain > Labels: candidate_oak_1_2, candidate_oak_1_4 > Fix For: 1.5.5 > > > Add an option to check data store consistency in oak-run. Along with the > consistency check it makes sense to have the option to dump all blob ids > and/or all the blob references available. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (OAK-4502) LucenePropertyIndex doesn't use filter's path for ACL checks of suggest queries
[
https://issues.apache.org/jira/browse/OAK-4502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dominique Jäggi closed OAK-4502.
bulk close after 1.5.5 release
> LucenePropertyIndex doesn't use filter's path for ACL checks of suggest
> queries
> ---
>
> Key: OAK-4502
> URL: https://issues.apache.org/jira/browse/OAK-4502
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Affects Versions: 1.4.1
> Environment: AEM 6.2 with Oak 1.4.1
>Reporter: Stefan Grinsted
>Assignee: Tommaso Teofili
> Labels: patch
> Fix For: 1.2.17, 1.5.5, 1.4.5
>
> Attachments: Screen Shot 2016-06-23 at 22.43.14.png, Screen Shot
> 2016-06-23 at 22.43.47.png
>
>
> When querying for suggestions, the {{LucenePropertyIndex}} performs the ACL
> checks for the suggested terms incorrectly if the {{oak:index}} definition is
> not located under the root.
> In my example, I have an {{oak:index}} definition under
> {{/content/wcgcom/demo/example/oak:index/lucene-suggest}} looking like this:
> {code}
> jcr:primaryType="oak:QueryIndexDefinition"
> async="async"
> compatVersion="{Long}2"
> reindex="{Boolean}false"
> reindexCount="{Long}5"
> type="lucene">
>
>
>
> jcr:primaryType="nt:unstructured"
> analyzed="{Boolean}true"
> isRegexp="{Boolean}true"
>
> name="jcr:(title|description)|title|subtitle|boldTitle"
> propertyIndex="{Boolean}true"
> useInSuggest="{Boolean}true"/>
>
>
>
> jcr:primaryType="nt:unstructured"
> suggestAnalyzed="{Boolean}true"
> suggestUpdateFrequencyMinutes="{Long}20"/>
>
> {code}
> And most relevant content under this path:
> {{/content/wcgcom/demo/example/home}}
> When inspecting the ACL checks happening in the suggestion part of
> {{LucenePropertyIndex#loadDocs}} it seems the Document's path as returned by
> {{retrievedDoc.get(FieldNames.PATH)}} starts from the root path of the index.
> So in this case an example of a document path from the index above could be
> {{/home/about-us/news/jcr:content/headerParagraph/shortheader}} (notice that
> it's missing the full path to the root of the JCR workspace (specifically
> missing {{/content/wcgcom/demo/example}} in this case)
> I believe this could be solved by simply prefixing the document path with
> {{filter.getPath()}}. And looking through the code, it looks like the same
> problem is present for the spellcheck type queries.
> Here's a patch that could potentially fix this (untested):
> {noformat}
> diff --git
> a/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/LucenePropertyIndex.java
>
> b/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/LucenePropertyIndex.java
> index 7e5291f..a262f3e 100644
> ---
> a/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/LucenePropertyIndex.java
> +++
> b/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/LucenePropertyIndex.java
> @@ -464,7 +464,7 @@ public class LucenePropertyIndex implements
> AdvancedQueryIndex, QueryIndex, Nati
> if (topDocs.totalHits > 0) {
> for (ScoreDoc doc : topDocs.scoreDocs) {
> Document retrievedDoc =
> searcher.doc(doc.doc);
> -if
> (filter.isAccessible(retrievedDoc.get(FieldNames.PATH))) {
> +if (filter.isAccessible(filter.getPath()
> + retrievedDoc.get(FieldNames.PATH))) {
> queue.add(new
> LuceneResultRow(suggestion.string));
> break;
> }
> @@ -492,7 +492,7 @@ public class LucenePropertyIndex implements
> AdvancedQueryIndex, QueryIndex, Nati
> if (topDocs.totalHits > 0) {
> for (ScoreDoc doc : topDocs.scoreDocs) {
> Document retrievedDoc =
> searcher.doc(doc.doc);
> -if
> (filter.isAccessible(retrievedDoc.get(FieldNames.PATH))) {
> +if (filter.isAccessible(filter.getPath()
> + retrievedDoc.get(FieldNames.PATH))) {
> queue.add(new
> Lu
[jira] [Closed] (OAK-4536) Avoid premature branch
[
https://issues.apache.org/jira/browse/OAK-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dominique Jäggi closed OAK-4536.
bulk close after 1.5.5 release
> Avoid premature branch
> --
>
> Key: OAK-4536
> URL: https://issues.apache.org/jira/browse/OAK-4536
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: core, documentmk
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
> Fix For: 1.6, 1.5.5
>
>
> Some usage patterns will lead to a premature branch created by the
> DocumentNodeStore. Every {{DocumentRootBuilder.purge()}} call currently
> causes a transition of the BranchState, from {{Unmodified}} to {{InMemory}}
> to {{Persisted}}. This means BranchState may reach {{Persisted}} even though
> {{update.limit}} is not reached.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (OAK-4369) Introduce interface for Secondary NodeStore provider
[
https://issues.apache.org/jira/browse/OAK-4369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dominique Jäggi closed OAK-4369.
bulk close after 1.5.5 release
> Introduce interface for Secondary NodeStore provider
>
>
> Key: OAK-4369
> URL: https://issues.apache.org/jira/browse/OAK-4369
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: core
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: 1.6, 1.5.5
>
>
> For using SegmentNodeStore as a persistent cache for DocumentNodeStore
> (OAK-4180) we need a way to access a _secondary_ NodeStore. This store should
> not be registered directly with the system but provides accessor for
> obtaining the node store instance
> {code}
> public interface SecondaryNodeStoreProvider {
> NodeStore getSecondaryStore();
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (OAK-4533) make DELAY_THRESHOLD & MAX_DELAY of ChangeProcessor configurable
[ https://issues.apache.org/jira/browse/OAK-4533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominique Jäggi closed OAK-4533. bulk close after 1.5.5 release > make DELAY_THRESHOLD & MAX_DELAY of ChangeProcessor configurable > > > Key: OAK-4533 > URL: https://issues.apache.org/jira/browse/OAK-4533 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: jcr >Affects Versions: 1.5.4 >Reporter: Stefan Egli >Assignee: Stefan Egli > Fix For: 1.5.5 > > > Currently DELAY_THRESHOLD & MAX_DELAY of ChangeProcessor are hardcoded at 0.8 > / 1. While we should come up with good defaults it might make sense to > have these values configurable too. The most simplistic could be via a > System.property for example. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (OAK-4488) Create separate reactor POM to perform releases
[
https://issues.apache.org/jira/browse/OAK-4488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dominique Jäggi closed OAK-4488.
bulk close after 1.5.5 release
> Create separate reactor POM to perform releases
> ---
>
> Key: OAK-4488
> URL: https://issues.apache.org/jira/browse/OAK-4488
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: parent
>Reporter: Francesco Mari
>Assignee: Francesco Mari
> Fix For: 1.6, 1.5.5
>
>
> Releases are currently performed from the root reactor POM. This triggers the
> execution of the {{release:prepare}} and {{release:perform}} goals on every
> module referenced from the reactor.
> This approach prevents the individual release of some sub-modules. To enable
> individual releases, the least disruptive approach would be the creation of
> another reactor POM to reference every module in Oak that needs to be
> released in one big bulk. In example, {{oak-release/pom.xml}} or something
> along these lines.
> The current reactor POM will remain untouched and will still reference every
> module in the project. This way, we will not have to change configuration of
> CI jobs out there.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (OAK-4537) rat-plugin does not ignore oak-segment-tar/target
[ https://issues.apache.org/jira/browse/OAK-4537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominique Jäggi closed OAK-4537. bulk close after 1.5.5 release > rat-plugin does not ignore oak-segment-tar/target > - > > Key: OAK-4537 > URL: https://issues.apache.org/jira/browse/OAK-4537 > Project: Jackrabbit Oak > Issue Type: Bug >Reporter: Davide Giannella >Assignee: Davide Giannella >Priority: Blocker > Fix For: 1.6, 1.5.5 > > > When running the release checks the target directory of oak-segment-tar is > not ignored. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (OAK-4538) IndexDefinition.createCodec class loading deadlock
[
https://issues.apache.org/jira/browse/OAK-4538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dominique Jäggi closed OAK-4538.
bulk close after 1.5.5 release
> IndexDefinition.createCodec class loading deadlock
> --
>
> Key: OAK-4538
> URL: https://issues.apache.org/jira/browse/OAK-4538
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene, query
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
> Labels: candidate_oak_1_0, candidate_oak_1_2
> Fix For: 1.5.5, 1.4.5
>
>
> Sometimes, when initializing an Oak Lucene index, a class loading deadlock
> can occur. Unfortunately, no deadlock is reported by the JVM when creating a
> full thread dump, but the thread dump typically shows the threads below. The
> root cause seems to be LUCENE-6482, and the reason for that is described in
> http://ternarysearch.blogspot.it/2013/07/static-initialization-deadlock.html
> I have created a simple, reproducible test case, and found a simple
> workaround in Oak, which is to load the OakCodec before a custom codec. This
> ensures the class OakCodec, and all superclasses, are loaded before the
> static initializer of Codec is run. Test case see below (un-commenting the
> commented line will make it work, otherwise the test results in a deadlock
> most of the time).
> {noformat}
> java.lang.Thread.State: RUNNABLE
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.IndexDefinition.createCodec(IndexDefinition.java:1301)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.IndexDefinition.(IndexDefinition.java:260)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.IndexDefinition.(IndexDefinition.java:228)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.IndexNode.open(IndexNode.java:48)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.IndexTracker.findIndexNode(IndexTracker.java:179)
> - locked <0x0007ff915448> (a
> org.apache.jackrabbit.oak.plugins.index.lucene.IndexTracker)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.IndexTracker.acquireIndexNode(IndexTracker.java:154)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex.getPlans(LucenePropertyIndex.java:250)
> at
> org.apache.jackrabbit.oak.query.QueryImpl.getBestSelectorExecutionPlan(QueryImpl.java:1016)
> at
> org.apache.jackrabbit.oak.query.QueryImpl.getBestSelectorExecutionPlan(QueryImpl.java:949)
> at
> org.apache.jackrabbit.oak.query.ast.SelectorImpl.prepare(SelectorImpl.java:288)
> at org.apache.jackrabbit.oak.query.QueryImpl.prepare(QueryImpl.java:631)
> at
> org.apache.jackrabbit.oak.query.QueryEngineImpl.prepareAndSelect(QueryEngineImpl.java:298)
> at
> org.apache.jackrabbit.oak.query.QueryEngineImpl.executeQuery(QueryEngineImpl.java:273)
> at
> org.apache.jackrabbit.oak.query.QueryEngineImpl.executeQuery(QueryEngineImpl.java:233)
> at
> org.apache.jackrabbit.oak.plugins.identifier.IdentifierManager.resolveUUID(IdentifierManager.java:314)
> at
> org.apache.jackrabbit.oak.plugins.identifier.IdentifierManager.resolveUUID(IdentifierManager.java:308)
> at
> org.apache.jackrabbit.oak.plugins.identifier.IdentifierManager.resolveUUID(IdentifierManager.java:304)
> at
> org.apache.jackrabbit.oak.plugins.identifier.IdentifierManager.getTree(IdentifierManager.java:133)
> at
> org.apache.jackrabbit.oak.security.authentication.token.TokenProviderImpl.getTokenInfo(TokenProviderImpl.java:250)
> at
> org.apache.jackrabbit.oak.security.authentication.token.TokenAuthentication.validateCredentials(TokenAuthentication.java:81)
> "aysnc-index-update-fulltext-async" prio=5 tid=0x7fe845e51800 nid=0xb407
> in Object.wait() [0x75f2f000]
>java.lang.Thread.State: RUNNABLE
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
> at java.lang.Class.newInstance(Class.java:379)
> at org.apache.lucene.util.NamedSPILoader.reload(NamedSPILoader.java:67)
> - locked <0x0007d2ba9120> (a org.apache.lucene.util.NamedSPILoader)
> at org.apache.lucene.util.NamedSPILoader.(NamedSPILoader.java:45)
> at org.apache.lucene.util.NamedSPILoader.(NamedSPILoader.java:37)
> at org.apache.lucene.codecs.Codec.(Codec.java:41)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.IndexDefinition.createCodec(IndexDefinition.java:1299)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.IndexDefini
[jira] [Closed] (OAK-3865) New strategy to optimize secondary reads
[ https://issues.apache.org/jira/browse/OAK-3865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominique Jäggi closed OAK-3865. bulk close after 1.5.5 release > New strategy to optimize secondary reads > > > Key: OAK-3865 > URL: https://issues.apache.org/jira/browse/OAK-3865 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: mongomk >Reporter: Tomek Rękawek >Assignee: Tomek Rękawek > Labels: performance > Fix For: 1.6, 1.5.5 > > Attachments: OAK-3865.patch, ReadDeepTreeNoCacheTest.patch, > clustered-oak-setup-improvements.pdf, diagram.png > > > *Introduction* > In the current trunk we'll only read document _D_ from the secondary instance > if: > (1) we have the parent _P_ of document _D_ cached and > (2) the parent hasn't been modified in 6 hours. > The OAK-2106 tried to optimise (2) by estimating lag using MongoDB replica > stats. It was unreliable, so the second approach was to read the last > revisions directly from each Mongo instance. If the modification date of _P_ > is before last revisions on all secondary Mongos, then secondary can be used. > The main problem with this approach is that we still need to have the _P_ to > be in cache. I think we need another way to optimise the secondary reading, > as right now only about 3% of requests connects to the secondary, which is > bad especially for the global-clustering case (Mongo and Oak instances across > the globe). The optimisation provided in OAK-2106 doesn't make the things > much better and may introduce some consistency issues. > *Proposal - tldr version* > Oak will remember the last revision it has ever seen. In the same time, it'll > query each secondary Mongo instance, asking what's the available stored root > revision. If all secondary instances have a root revision >= last revision > seen by a given Oak instance, it's safe to use the secondary read preference. > *Proposal* > I had following constraints in mind preparing this: > 1. Let's assume we have a sequence of commits with revisions _R1_, _R2_ and > _R3_ modifying nodes _N1_, _N2_ and _N3_. If we already read the _N1_ from > revision _R2_ then reading from a secondary shouldn't result in getting older > revision (eg. _R1_). > 2. If an Oak instance modifies a document, then reading from a secondary > shouldn't result in getting the old version (before modification). > So, let's have two maps: > * _M1_ the most recent document revision read from the Mongo for each cluster > id, > * _M2_ the oldest last rev value for root document for each cluster id read > from all the secondary instances. > Maintaining _M1_: > For every read from the Mongo we'll check if the lastRev for some cluster id > is newer than _M1_ entry. If so, we'll update _M1_. For all writes we'll add > the saved revision id with the current cluster id in _M1_. > Maintaining _M2_: > It should be periodically updated. Such mechanism is already prepared in the > OAK-2106 patch. > The method deciding whether we can read from the secondary instance should > compare two maps. If all entries in _M2_ are newer than _M1_ it means that > the secondary instances contains at least as new repository state as we > already accessed and therefore it's safe to read from secondary. > Regarding the documents modified by the local Oak instance, we should > remember all the locally-modified paths and their revisions and use primary > Mongo to access them as long as the changes are not replicated to all the > secondaries. When the secondaries are up to date with the modification, we > can remove it from the local-changes collections. > Attached image diagram.png presents the idea. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (OAK-4515) Catch NPE and log serverResult in MongoDocumentStore.determineServerTimeDifferenceMillis
[
https://issues.apache.org/jira/browse/OAK-4515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dominique Jäggi closed OAK-4515.
bulk close after 1.5.5 release
> Catch NPE and log serverResult in
> MongoDocumentStore.determineServerTimeDifferenceMillis
>
>
> Key: OAK-4515
> URL: https://issues.apache.org/jira/browse/OAK-4515
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: mongomk
>Affects Versions: 1.5.4, 1.4.4
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: 1.6, 1.5.5, 1.4.5
>
>
> As a follow-up of OAK-4107 this is about
> * backporting OAK-4107 to 1.4.5
> * but additionally, log more details, including
> {{serverStatus.getErrorMessage()}} and {{serverStatus.getException()}}
> ** apply this to both 1.4.5 and 1.5.5
> See OAK-4107 and there-attached
> [patch|https://issues.apache.org/jira/secure/attachment/12814064/OAK-4107.1_4_branch.patch]
> (with suggested change from [~chetanm])
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (OAK-4509) RDBDocumentStore: low-level read method should also support condition on MODIFIED value
[ https://issues.apache.org/jira/browse/OAK-4509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominique Jäggi closed OAK-4509. bulk close after 1.5.5 release > RDBDocumentStore: low-level read method should also support condition on > MODIFIED value > --- > > Key: OAK-4509 > URL: https://issues.apache.org/jira/browse/OAK-4509 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: rdbmk >Affects Versions: 1.0.31, 1.2.16, 1.5.4, 1.4.4 >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Fix For: 1.0.32, 1.2.17, 1.5.5, 1.4.5 > > > This would simplify the fix for OAK-4494. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (OAK-4527) [oak-blob-cloud] Access parameters configured leak out in the exception message
[ https://issues.apache.org/jira/browse/OAK-4527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominique Jäggi closed OAK-4527. bulk close after 1.5.5 release > [oak-blob-cloud] Access parameters configured leak out in the exception > message > --- > > Key: OAK-4527 > URL: https://issues.apache.org/jira/browse/OAK-4527 > Project: Jackrabbit Oak > Issue Type: Bug > Components: blob >Reporter: Amit Jain >Assignee: Amit Jain > Labels: candidate_oak_1_2, candidate_oak_1_4 > Fix For: 1.5.5 > > > S3Backend when not initialized properly due to some configuration error logs > the config parameters for debugging which includes the accessKey and > secretKey parameters. > The accessKey/secretKey parameters should not be logged -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (OAK-4503) Update count increases with rebase
[
https://issues.apache.org/jira/browse/OAK-4503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dominique Jäggi closed OAK-4503.
bulk close after 1.5.5 release
> Update count increases with rebase
> --
>
> Key: OAK-4503
> URL: https://issues.apache.org/jira/browse/OAK-4503
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, documentmk
>Affects Versions: 1.0, 1.2, 1.4
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
>Priority: Minor
> Labels: candidate_oak_1_0, candidate_oak_1_2, candidate_oak_1_4
> Fix For: 1.6, 1.5.5
>
>
> The update count in {{DocumentRootBuilder}} increases with the number of
> changes in memory when {{rebase()}} is called. The update count should stay
> the same because a rebase does not affect the number of in-memory changes.
> This may lead to premature creation of a branch when pending changes are
> rebased too often. E.g. when Node.isLocked() is called frequently.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (OAK-3629) Index corruption seen with CopyOnRead when index defnition is recreated
[
https://issues.apache.org/jira/browse/OAK-3629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dominique Jäggi closed OAK-3629.
bulk close after 1.5.5 release
> Index corruption seen with CopyOnRead when index defnition is recreated
> ---
>
> Key: OAK-3629
> URL: https://issues.apache.org/jira/browse/OAK-3629
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Blocker
> Labels: candidate_oak_1_0, candidate_oak_1_2, candidate_oak_1_4
> Fix For: 1.6, 1.5.5
>
>
> CopyOnRead logic relies on {{reindexCount}} to determine the name of
> directory in which index files would be copied. In normal flow if the index
> is reindexed then this count would get increased and newer index files would
> get copied to a new directory.
> However if the index definition node gets recreated due to some deployment
> process then this count gets reset to 0. Due to which newly created index
> files from reindexing would start getting copied to already existing
> directory and that can lead to corruption.
> So what happened here was
> # System started with index definition I1 and indexing got complete with
> index files saved under index/hash(indexpath)/1 (where 1 is current reindex
> count)
> # A new index definition package was deployed which reset the index count.
> Now reindex happened again and the CopyOnRead logic per current design reused
> the existing index directory. And it so happens that Lucene create file with
> same name and same size but different content. This trips the CopyOnRead
> defense of length based index corruption check and thus cause new lucene
> index to corrupt
> *Note that here corruption is transient i.e. persisted index is not
> corrupted*. Just that locally copied index gets corrupted. Cleaning up the
> index directory would fix the issue and that can be used as a workaround.
> *Fix*
> After discussing with [~tmueller] following approach can be used.
> Instead of relying on reindex count we can maintain a hidden randomly
> generated uuid and store it in the index config. This would be used to derive
> the name of directory on filesystem. If the index definition gets reset then
> the uuid can be regenerated.
> *Workaround*
> Clean the directory used by CopyOnRead which is /index before
> restart
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (OAK-4532) race-condition in commit-rate-limiter
[
https://issues.apache.org/jira/browse/OAK-4532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dominique Jäggi closed OAK-4532.
bulk close after 1.5.5 release
> race-condition in commit-rate-limiter
> -
>
> Key: OAK-4532
> URL: https://issues.apache.org/jira/browse/OAK-4532
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.5.4
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: 1.5.5
>
>
> [CommitRateLimiter.delay|https://github.com/apache/jackrabbit-oak/blob/jackrabbit-oak-1.5.4/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/observation/CommitRateLimiter.java#L81]
> has a race-condition when the queue length drops below thres-hold right when
> {{delay()}} is called. Consider the following steps:
> * thread T1 enters {{delay()}} with a positive value for {{delay}} but gets
> paused right after the check for {{delay>0}}
> * thread T2 enters {{setDelay(0)}}, thus goes into the synchronized block and
> does a notifyAll
> * thread T1 continues in {{delay()}} after above mentioned check, thus now
> goes into the synchronized block - at this stage {{delay}} is {{0}} (as it's
> volatile) - thus it sets {{dt=0}}.
> * thread T1 then goes and calls {{wait(0)}} - which is an infinite wait,
> until it gets notified. This can be forever if the threshold is never ever
> hit again.
> Would suggest to do a {{while}} loop rather than a {{do-while}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (OAK-4507) [oak-mongo.js] oak.indexStats() does not compute counts properly
[
https://issues.apache.org/jira/browse/OAK-4507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dominique Jäggi closed OAK-4507.
bulk close after 1.5.5 release
> [oak-mongo.js] oak.indexStats() does not compute counts properly
>
>
> Key: OAK-4507
> URL: https://issues.apache.org/jira/browse/OAK-4507
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: run
>Affects Versions: 1.0, 1.2, 1.4
>Reporter: Kevin Wellenzohn
>Assignee: Marcel Reutegger
>Priority: Trivial
> Fix For: 1.6, 1.5.5
>
> Attachments: OAK-4507.patch
>
>
> Some methods in oak-mongo.js that use the pathFilter function consider paths
> that they shouldn't consider. For example, in a AEM installation
> oak.countChildren("/oak:index/slingResource") counts the children of the
> following paths:
> - /oak:index/slingResource
> - /oak:index/slingResourceSuperType
> - /oak:index/slingResourceType
> - /oak:index/slingResources
> The reason is that pathFilter function builds a RegExp that is not terminated
> by a path separator and hence matches more paths than it should.
> Issues occur in the following functions:
> - oak.indexStats()
> - oak.countChildren()
> - oak.forEachChild()
> - oak.getChildStats()
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3613) Backport TarMK revision gc related issues
[ https://issues.apache.org/jira/browse/OAK-3613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15370643#comment-15370643 ] Jonas Oskö commented on OAK-3613: - Hello I am on vacation and will be back on Aug 15th. Meanwhile, please contact Jimmy Lundström (jimmy.lundst...@hm.com) for any CMS/AEM-related questions. Best / Jonas The information contained in this e-mail message may be privileged, confidential, and protected from disclosure. Any unauthorized use, printing, copying, disclosure or dissemination of this communication may be subject to legal restriction or sanction. If you think that you have received this e-mail message in error, please reply to the sender and delete this message from your computer. > Backport TarMK revision gc related issues > - > > Key: OAK-3613 > URL: https://issues.apache.org/jira/browse/OAK-3613 > Project: Jackrabbit Oak > Issue Type: Task > Components: segmentmk >Reporter: Michael Dürig >Assignee: Michael Dürig > Labels: compaction, gc > Fix For: 1.0.33 > > Attachments: > 0001-OAK-2870-Introduce-a-SegmentNodeStoreBuilder-to-help.patch, > 1.2-OAK-2870.patch, OAK-1995-1.0.patch, OAK-1995-1.2.zip, OsgiUtil-1.0.patch, > OsgiUtil-1.2.patch > > > Some of the issues related to TarMK revision gc should be back ported to the > branches. This issue is for keeping track of which issues and which svn > revisions we consider for back porting. The task consists of the following > steps: > # Identify issue to back port > # Merge the respective commits into a private forks of the 1.0 and 1.2 > branches > # Run tests on builds from the private forks > # On success merge the private forks to the 1.0 and 1.2 branches and update > the fix versions of the respective issues. > * Update the svn merge info with the respective merged svn revisions. > * Update the fix versions of the affected issues. > [~dhasler]: FYI > [~alex.parvulescu], [~frm]: please refrain from merging potential conflicting > changes into the branches in the meanwhile. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3126) Enable HybridMapFactory by default
[ https://issues.apache.org/jira/browse/OAK-3126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominique Jäggi updated OAK-3126: - Fix Version/s: (was: 1.0.32) 1.0.33 bulk move due 1.0.32 release > Enable HybridMapFactory by default > -- > > Key: OAK-3126 > URL: https://issues.apache.org/jira/browse/OAK-3126 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core, mongomk >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger > Fix For: 1.0.33 > > > This is a follow up issue of OAK-3112. The HybridMapFactory should be enabled > by default once it has proven to be stable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3613) Backport TarMK revision gc related issues
[ https://issues.apache.org/jira/browse/OAK-3613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominique Jäggi updated OAK-3613: - Fix Version/s: (was: 1.0.32) 1.0.33 bulk move due 1.0.32 release > Backport TarMK revision gc related issues > - > > Key: OAK-3613 > URL: https://issues.apache.org/jira/browse/OAK-3613 > Project: Jackrabbit Oak > Issue Type: Task > Components: segmentmk >Reporter: Michael Dürig >Assignee: Michael Dürig > Labels: compaction, gc > Fix For: 1.0.33 > > Attachments: > 0001-OAK-2870-Introduce-a-SegmentNodeStoreBuilder-to-help.patch, > 1.2-OAK-2870.patch, OAK-1995-1.0.patch, OAK-1995-1.2.zip, OsgiUtil-1.0.patch, > OsgiUtil-1.2.patch > > > Some of the issues related to TarMK revision gc should be back ported to the > branches. This issue is for keeping track of which issues and which svn > revisions we consider for back porting. The task consists of the following > steps: > # Identify issue to back port > # Merge the respective commits into a private forks of the 1.0 and 1.2 > branches > # Run tests on builds from the private forks > # On success merge the private forks to the 1.0 and 1.2 branches and update > the fix versions of the respective issues. > * Update the svn merge info with the respective merged svn revisions. > * Update the fix versions of the affected issues. > [~dhasler]: FYI > [~alex.parvulescu], [~frm]: please refrain from merging potential conflicting > changes into the branches in the meanwhile. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-4541) Update Oak to Jackrabbit 2.13.0
[ https://issues.apache.org/jira/browse/OAK-4541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15370620#comment-15370620 ] Julian Reschke commented on OAK-4541: - The one causing this likely is JCR-3987 -- it's just not yet clear to me whether the change is incorrect, or whether the test case is making wrong assumptions about that method... > Update Oak to Jackrabbit 2.13.0 > --- > > Key: OAK-4541 > URL: https://issues.apache.org/jira/browse/OAK-4541 > Project: Jackrabbit Oak > Issue Type: Task >Affects Versions: 1.5.5 >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Fix For: 1.6 > > Attachments: OAK-4541.diff > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4105) Implement FileStore.size through FileStore.approximateSize
[
https://issues.apache.org/jira/browse/OAK-4105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Mari updated OAK-4105:
Assignee: Andrei Dulceanu (was: Francesco Mari)
> Implement FileStore.size through FileStore.approximateSize
> --
>
> Key: OAK-4105
> URL: https://issues.apache.org/jira/browse/OAK-4105
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: segment-tar
>Reporter: Michael Dürig
>Assignee: Andrei Dulceanu
>Priority: Minor
> Labels: resilience
> Fix For: Segment Tar 0.0.4
>
>
> {{FileStore.size()}} is prone to lock contention and should not be called too
> often. As OAK-2879 already introduced an approach for tracking the current
> size of the file store without having to lock, we might as well promote his
> to be "the official" implementation.
> [~frm] WDYT?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4105) Implement FileStore.size through FileStore.approximateSize
[
https://issues.apache.org/jira/browse/OAK-4105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Mari updated OAK-4105:
Fix Version/s: (was: 1.6)
> Implement FileStore.size through FileStore.approximateSize
> --
>
> Key: OAK-4105
> URL: https://issues.apache.org/jira/browse/OAK-4105
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: segment-tar
>Reporter: Michael Dürig
>Priority: Minor
> Labels: resilience
> Fix For: Segment Tar 0.0.4
>
>
> {{FileStore.size()}} is prone to lock contention and should not be called too
> often. As OAK-2879 already introduced an approach for tracking the current
> size of the file store without having to lock, we might as well promote his
> to be "the official" implementation.
> [~frm] WDYT?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4103) Replace journal.log with an in place journal
[
https://issues.apache.org/jira/browse/OAK-4103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15370618#comment-15370618
]
Andrei Dulceanu commented on OAK-4103:
--
[~frm] I'd like to work on this issue. Can you please assign it to me?
> Replace journal.log with an in place journal
>
>
> Key: OAK-4103
> URL: https://issues.apache.org/jira/browse/OAK-4103
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: segment-tar
>Reporter: Michael Dürig
>Priority: Minor
> Labels: resilience
> Fix For: 1.6, Segment Tar 0.0.4
>
>
> Instead of writing the current head revision to the {{journal.log}} file we
> could make it an integral part of the node states: as OAK-3804 demonstrates
> we already have very good heuristics to reconstruct a lost journal. If we add
> the right annotations to the root node states this could replace the current
> approach. The latter is problematic as it relies on the flush thread properly
> and timely updating {{journal.log}}. See e.g. OAK-3303.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (OAK-4105) Implement FileStore.size through FileStore.approximateSize
[
https://issues.apache.org/jira/browse/OAK-4105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Mari reassigned OAK-4105:
---
Assignee: Francesco Mari
> Implement FileStore.size through FileStore.approximateSize
> --
>
> Key: OAK-4105
> URL: https://issues.apache.org/jira/browse/OAK-4105
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: segment-tar
>Reporter: Michael Dürig
>Assignee: Francesco Mari
>Priority: Minor
> Labels: resilience
> Fix For: Segment Tar 0.0.4
>
>
> {{FileStore.size()}} is prone to lock contention and should not be called too
> often. As OAK-2879 already introduced an approach for tracking the current
> size of the file store without having to lock, we might as well promote his
> to be "the official" implementation.
> [~frm] WDYT?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4105) Implement FileStore.size through FileStore.approximateSize
[
https://issues.apache.org/jira/browse/OAK-4105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15370614#comment-15370614
]
Andrei Dulceanu commented on OAK-4105:
--
[~frm] I'd like to work on this issue. Can you please assign it to me?
> Implement FileStore.size through FileStore.approximateSize
> --
>
> Key: OAK-4105
> URL: https://issues.apache.org/jira/browse/OAK-4105
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: segment-tar
>Reporter: Michael Dürig
>Priority: Minor
> Labels: resilience
> Fix For: 1.6, Segment Tar 0.0.4
>
>
> {{FileStore.size()}} is prone to lock contention and should not be called too
> often. As OAK-2879 already introduced an approach for tracking the current
> size of the file store without having to lock, we might as well promote his
> to be "the official" implementation.
> [~frm] WDYT?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4201) Add an index of binary references in a tar file
[
https://issues.apache.org/jira/browse/OAK-4201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Mari updated OAK-4201:
Attachment: OAK-4201-01.patch
[^OAK-4201-01.patch] saves every external binary identifier in a separate entry
in the TAR file. When collecting external binary references, is not needed to
scan and read every segment anymore. For this reason, this patch also removes
the list of external binary references from the segment header.
[~alex.parvulescu], [~mduerig], can you have a look at this patch? You can also
follow this patch commit-by-commit
[here|https://github.com/francescomari/jackrabbit-oak/commits/bid], every
commit contains a more detailed description of what I changed and why.
> Add an index of binary references in a tar file
> ---
>
> Key: OAK-4201
> URL: https://issues.apache.org/jira/browse/OAK-4201
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Reporter: Chetan Mehrotra
>Assignee: Francesco Mari
> Fix For: Segment Tar 0.0.4
>
> Attachments: OAK-4201-01.patch
>
>
> Currently for Blob GC in case of segment {{SegmentBlobReferenceRetriever}}
> goes through all tar files and extracts the binary references. This has 2
> issues
> # Logic has go through all the segments in all tar files
> # All segments get loaded in memory once which would affect normal system
> performance
> This process can be optimized if we also write a file entry in tar (similar
> to gph i.e. graph and idx i.e. index files) which has entries of all binary
> references referred to in any segment present in that tar file. Then GC logic
> would just have read this file and avoid scanning all the segments
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4541) Update Oak to Jackrabbit 2.13.0
[ https://issues.apache.org/jira/browse/OAK-4541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15370604#comment-15370604 ] angela commented on OAK-4541: - no... what are the changes included in that jackrabbit version? > Update Oak to Jackrabbit 2.13.0 > --- > > Key: OAK-4541 > URL: https://issues.apache.org/jira/browse/OAK-4541 > Project: Jackrabbit Oak > Issue Type: Task >Affects Versions: 1.5.5 >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Fix For: 1.6 > > Attachments: OAK-4541.diff > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4201) Add an index of binary references in a tar file
[
https://issues.apache.org/jira/browse/OAK-4201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Mari updated OAK-4201:
Fix Version/s: (was: 1.6)
> Add an index of binary references in a tar file
> ---
>
> Key: OAK-4201
> URL: https://issues.apache.org/jira/browse/OAK-4201
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Reporter: Chetan Mehrotra
>Assignee: Francesco Mari
> Fix For: Segment Tar 0.0.4
>
>
> Currently for Blob GC in case of segment {{SegmentBlobReferenceRetriever}}
> goes through all tar files and extracts the binary references. This has 2
> issues
> # Logic has go through all the segments in all tar files
> # All segments get loaded in memory once which would affect normal system
> performance
> This process can be optimized if we also write a file entry in tar (similar
> to gph i.e. graph and idx i.e. index files) which has entries of all binary
> references referred to in any segment present in that tar file. Then GC logic
> would just have read this file and avoid scanning all the segments
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (OAK-4541) Update Oak to Jackrabbit 2.13.0
[
https://issues.apache.org/jira/browse/OAK-4541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15370563#comment-15370563
]
Julian Reschke edited comment on OAK-4541 at 7/11/16 11:33 AM:
---
(this leads to test failures in oak-jcr, to be investigated)
{noformat}
testCreateWithIntermediateReadDeny2(org.apache.jackrabbit.oak.jcr.security.authorization.UserManagementTest)
Time elapsed: 0.013 sec <<< ERROR!
javax.jcr.PathNotFoundException: Node with path
/rep:security/rep:authorizables/rep:groups/a does not exist.
at
org.apache.jackrabbit.oak.jcr.session.SessionImpl.getNode(SessionImpl.java:305)
at
org.apache.jackrabbit.oak.jcr.security.authorization.UserManagementTest.testCreateWithIntermediateReadDeny2(UserManagementTest.java:219)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
{noformat}
[~anchela] - any idea what this could be?
was (Author: reschke):
(this leads to test failures in oak-jcr, to be investigated)
> Update Oak to Jackrabbit 2.13.0
> ---
>
> Key: OAK-4541
> URL: https://issues.apache.org/jira/browse/OAK-4541
> Project: Jackrabbit Oak
> Issue Type: Task
>Affects Versions: 1.5.5
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Fix For: 1.6
>
> Attachments: OAK-4541.diff
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4541) Update Oak to Jackrabbit 2.13.0
[ https://issues.apache.org/jira/browse/OAK-4541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-4541: Attachment: OAK-4541.diff (this leads to test failures in oak-jcr, to be investigated) > Update Oak to Jackrabbit 2.13.0 > --- > > Key: OAK-4541 > URL: https://issues.apache.org/jira/browse/OAK-4541 > Project: Jackrabbit Oak > Issue Type: Task >Affects Versions: 1.5.5 >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Fix For: 1.6 > > Attachments: OAK-4541.diff > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4541) Update Oak to Jackrabbit 2.13.0
[ https://issues.apache.org/jira/browse/OAK-4541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-4541: Affects Version/s: 1.5.5 > Update Oak to Jackrabbit 2.13.0 > --- > > Key: OAK-4541 > URL: https://issues.apache.org/jira/browse/OAK-4541 > Project: Jackrabbit Oak > Issue Type: Task >Affects Versions: 1.5.5 >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Fix For: 1.6 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
