[jira] [Commented] (OAK-6165) Create compound index on _sdType and _sdMaxRevTime (RDB)
[ https://issues.apache.org/jira/browse/OAK-6165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15996182#comment-15996182 ] Chetan Mehrotra commented on OAK-6165: -- bq. We can't create indices until these indeed are DB columns, which is a non-trivial change. Ack and we should then look into making that change. Probably some other '_xxx' props in NodeDocument may also require a first class column support in DB row and we should look into those and determine the final schema. Then we would need to decide for upgrade i.e. some tooling to migrate existing tables to newer format > Create compound index on _sdType and _sdMaxRevTime (RDB) > > > Key: OAK-6165 > URL: https://issues.apache.org/jira/browse/OAK-6165 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: rdbmk >Reporter: Chetan Mehrotra >Assignee: Julian Reschke > Fix For: 1.8 > > > Clone for OAK-6129 for RDB i.e. create index on OAK-6129on _sdType and > _sdMaxRevTime. This is required to run queries issued by the Revision GC > efficiently. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (OAK-6165) Create compound index on _sdType and _sdMaxRevTime (RDB)
[ https://issues.apache.org/jira/browse/OAK-6165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15996179#comment-15996179 ] Julian Reschke commented on OAK-6165: - We can't create indices until these indeed are DB columns, which is a non-trivial change. The lack of a direct sdtype mapping currently is worked around by using path constraints on _ID. > Create compound index on _sdType and _sdMaxRevTime (RDB) > > > Key: OAK-6165 > URL: https://issues.apache.org/jira/browse/OAK-6165 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: rdbmk >Reporter: Chetan Mehrotra >Assignee: Julian Reschke > Fix For: 1.8 > > > Clone for OAK-6129 for RDB i.e. create index on OAK-6129on _sdType and > _sdMaxRevTime. This is required to run queries issued by the Revision GC > efficiently. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (OAK-2808) Active deletion of 'deleted' Lucene index files from DataStore without relying on full scale Blob GC
[ https://issues.apache.org/jira/browse/OAK-2808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15994362#comment-15994362 ] Chetan Mehrotra edited comment on OAK-2808 at 5/4/17 4:20 AM: -- bq. If blobs are removed after 30 minutes, and then one tries to rollback the repository state to before that (for the segment store, truncate the journal to what it was 31 minutes ago), the index would become corrupt. Yes that would be the case but then only guarantee we make with repository consistency at older revision is one where state is accessed based on some checkpoint. Any state beyond last valid checkpoint may not be consistent. If this is required then this feature can be disabled on those setups bq. An safer alternative to active deletion is to run revision garbage collection / segment store compaction, followed by datastore garbage collection. Thats the current state. However current cycle is set at weekly. And given DataStore GC for large repository takes time (mark phase on DocumentNodeStore specially and deletion in S3 is slow) its not feasible to run them frequently. May be for SegmentNodeStore with online gc we can run it frequently but that would need to be validated. Even then it would be problem for setup involving shared DataStore i.e. multiple SegmentNodeStore setups sharing same DataStore. In such deployment the BlobGC requires coordination across various nodes. bq. Basically, run the regular index update (which stores binaries in the datastore) much less frequently, for example just once per 5 minutes That would be tricky. If we make indexing less frequent then each cycle diff would take longer and it can lead to that indexing cycle take much longer causing the next cycle to take more time. We have seen this in few setups where if indexing starts lagging behind once and system is in active use then there is a high change of indexing lag becoming larger and larger (/cc [~stefan.eissing]) was (Author: chetanm): bq. If blobs are removed after 30 minutes, and then one tries to rollback the repository state to before that (for the segment store, truncate the journal to what it was 31 minutes ago), the index would become corrupt. Yes that would be the case but then only guarantee we make with repository consistency at older revision is one where state is accessed based on some checkpoint. Any state beyond last valid checkpoint may not be consistent. If this is required then this feature can be disabled on those setups bq. An safer alternative to active deletion is to run revision garbage collection / segment store compaction, followed by datastore garbage collection. Thats the current state. However current cycle is set at weekly. And given DataStore GC for large repository takes time (mark phase on DocumentNodeStore specially and deletion in S3 is slow) its not feasible to run them frequently. May be for SegmentNodeStore with online gc we can run it frequently but that would need to be validated. bq. Basically, run the regular index update (which stores binaries in the datastore) much less frequently, for example just once per 5 minutes That would be tricky. If we make indexing less frequent then each cycle diff would take longer and it can lead to that indexing cycle take much longer causing the next cycle to take more time. We have seen this in few setups where if indexing starts lagging behind once and system is in active use then there is a high change of indexing lag becoming larger and larger (/cc [~stefan.eissing]) > Active deletion of 'deleted' Lucene index files from DataStore without > relying on full scale Blob GC > > > Key: OAK-2808 > URL: https://issues.apache.org/jira/browse/OAK-2808 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: lucene >Reporter: Chetan Mehrotra >Assignee: Thomas Mueller > Labels: datastore, performance > Fix For: 1.8 > > Attachments: copyonread-stats.png, OAK-2808-1.patch > > > With storing of Lucene index files within DataStore our usage pattern > of DataStore has changed between JR2 and Oak. > With JR2 the writes were mostly application based i.e. if application > stores a pdf/image file then that would be stored in DataStore. JR2 by > default would not write stuff to DataStore. Further in deployment > where large number of binary content is present then systems tend to > share the DataStore to avoid duplication of storage. In such cases > running Blob GC is a non trivial task as it involves a manual step and > coordination across multiple deployments. Due to this systems tend to > delay frequency of GC > Now with Oak apart from application the Oak system itself *actively* > uses the DataStore
[jira] [Commented] (OAK-6129) Create compound index on _sdType and _sdMaxRevTime
[
https://issues.apache.org/jira/browse/OAK-6129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15996156#comment-15996156
]
Chetan Mehrotra commented on OAK-6129:
--
Opened OAK-6165 to track pending work related to RDB
> Create compound index on _sdType and _sdMaxRevTime
> --
>
> Key: OAK-6129
> URL: https://issues.apache.org/jira/browse/OAK-6129
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: mongomk
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
> Fix For: 1.7.0, 1.8
>
>
> Replace the current index on {{_sdType}} with a partial index on {{_sdType}}
> and {{_sdMaxRevTime}}. This is required to run queries issued by the Revision
> GC efficiently.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (OAK-6165) Create compound index on _sdType and _sdMaxRevTime (RDB)
Chetan Mehrotra created OAK-6165: Summary: Create compound index on _sdType and _sdMaxRevTime (RDB) Key: OAK-6165 URL: https://issues.apache.org/jira/browse/OAK-6165 Project: Jackrabbit Oak Issue Type: Improvement Components: rdbmk Reporter: Chetan Mehrotra Assignee: Julian Reschke Fix For: 1.8 Clone for OAK-6129 for RDB i.e. create index on OAK-6129on _sdType and _sdMaxRevTime. This is required to run queries issued by the Revision GC efficiently. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (OAK-5898) Revision GC command line tool
[ https://issues.apache.org/jira/browse/OAK-5898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15996144#comment-15996144 ] Chetan Mehrotra commented on OAK-5898: -- [~mreutegg] Can this tool be used with older versions of Oak (< 1.7.0)? If it does not modify the data model but just reset the revision commit root values then it would benefit older versions also > Revision GC command line tool > - > > Key: OAK-5898 > URL: https://issues.apache.org/jira/browse/OAK-5898 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: documentmk, run >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger > Fix For: 1.7.0, 1.8 > > > Revision GC can be triggered on a DocumentNodeStore on each node in a > cluster. A common setup with Apache Sling on top of Oak has a scheduled task > for the leader node in a cluster that triggers the Revision GC once a day. > For testing, maintenance and operational purpose it would be good to have an > alternative that can be triggered from the command line. > A potential solution is a new run mode in oak-run. It would bootstrap a > DocumentStore implementation (MongoDB or RDB) with a read-only > DocumentNodeStore and run revision GC. The command should probably support > options like: > - maxRevisionAge as defined in VersionGarbageCollector.gc() > - maxGCTime that limits the time GC will run until it will be canceled > automatically. > - delay as proposed in OAK-4780 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (OAK-6164) IOUtils.nextPowerOf2() returns lower power of 2 for very high int values
[ https://issues.apache.org/jira/browse/OAK-6164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Ryan updated OAK-6164: --- Attachment: OAK-6164.patch.2 As I thought a bit about patch 1, it occurred to me that adding a throws declaration for IllegalArgumentException is not really needed since it is a RuntimeException, but doing so changes the public API signature. So I've attached OAK-6164.patch.2 which removes the throws declaration. > IOUtils.nextPowerOf2() returns lower power of 2 for very high int values > > > Key: OAK-6164 > URL: https://issues.apache.org/jira/browse/OAK-6164 > Project: Jackrabbit Oak > Issue Type: Bug >Reporter: Matt Ryan >Priority: Minor > Attachments: OAK-6164.patch.1, OAK-6164.patch.2 > > > In the IOUtils.nextPowerOf2() method, all int values are accepted as input. > However, there are valid signed integer values that this method accepts as > input, but for which a lower power of 2 value is returned. > This occurs for values that are valid signed integer values that are greater > than the highest possible power of two value in the signed integer range. > Signed integer values have the maximum value of 0x7FFF, but the maximum > possible power of two in the signed integer range is 0x4000. (The > current implementation incorrectly identifies the maximum possible power of > two as 0x3FFF, due to how it is computed by doing integer division of > 0x7FFF / 2.) > In the current implementation any input in the range of [0x4000, > 0x7FFF] is a valid signed integer input, but the method will return > 0x3FFF as the next valid max power of 2. > Two minor things need to be fixed: > * If the input is 0x4000, the return value needs to be 0x4000, > instead of 0x3FFF which is not a valid power of 2. > * If the input is in the range [0x4001, 0x7FFF] I propose the method > should instead throw an IllegalArgumentException and indicate that it is not > possible to compute a next power of 2 for a number in that range. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (OAK-6164) IOUtils.nextPowerOf2() returns lower power of 2 for very high int values
[ https://issues.apache.org/jira/browse/OAK-6164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Ryan updated OAK-6164: --- Attachment: OAK-6164.patch.1 Attached patch with a fix, and with unit test for IOUtils.nextPowerOf2(). > IOUtils.nextPowerOf2() returns lower power of 2 for very high int values > > > Key: OAK-6164 > URL: https://issues.apache.org/jira/browse/OAK-6164 > Project: Jackrabbit Oak > Issue Type: Bug >Reporter: Matt Ryan >Priority: Minor > Attachments: OAK-6164.patch.1 > > > In the IOUtils.nextPowerOf2() method, all int values are accepted as input. > However, there are valid signed integer values that this method accepts as > input, but for which a lower power of 2 value is returned. > This occurs for values that are valid signed integer values that are greater > than the highest possible power of two value in the signed integer range. > Signed integer values have the maximum value of 0x7FFF, but the maximum > possible power of two in the signed integer range is 0x4000. (The > current implementation incorrectly identifies the maximum possible power of > two as 0x3FFF, due to how it is computed by doing integer division of > 0x7FFF / 2.) > In the current implementation any input in the range of [0x4000, > 0x7FFF] is a valid signed integer input, but the method will return > 0x3FFF as the next valid max power of 2. > Two minor things need to be fixed: > * If the input is 0x4000, the return value needs to be 0x4000, > instead of 0x3FFF which is not a valid power of 2. > * If the input is in the range [0x4001, 0x7FFF] I propose the method > should instead throw an IllegalArgumentException and indicate that it is not > possible to compute a next power of 2 for a number in that range. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (OAK-6164) IOUtils.nextPowerOf2() returns lower power of 2 for very high int values
[ https://issues.apache.org/jira/browse/OAK-6164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15995686#comment-15995686 ] Matt Ryan commented on OAK-6164: I have a patch for this, with a unit test, that I will submit shortly. > IOUtils.nextPowerOf2() returns lower power of 2 for very high int values > > > Key: OAK-6164 > URL: https://issues.apache.org/jira/browse/OAK-6164 > Project: Jackrabbit Oak > Issue Type: Bug >Reporter: Matt Ryan >Priority: Minor > > In the IOUtils.nextPowerOf2() method, all int values are accepted as input. > However, there are valid signed integer values that this method accepts as > input, but for which a lower power of 2 value is returned. > This occurs for values that are valid signed integer values that are greater > than the highest possible power of two value in the signed integer range. > Signed integer values have the maximum value of 0x7FFF, but the maximum > possible power of two in the signed integer range is 0x4000. (The > current implementation incorrectly identifies the maximum possible power of > two as 0x3FFF, due to how it is computed by doing integer division of > 0x7FFF / 2.) > In the current implementation any input in the range of [0x4000, > 0x7FFF] is a valid signed integer input, but the method will return > 0x3FFF as the next valid max power of 2. > Two minor things need to be fixed: > * If the input is 0x4000, the return value needs to be 0x4000, > instead of 0x3FFF which is not a valid power of 2. > * If the input is in the range [0x4001, 0x7FFF] I propose the method > should instead throw an IllegalArgumentException and indicate that it is not > possible to compute a next power of 2 for a number in that range. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (OAK-6164) IOUtils.nextPowerOf2() returns lower power of 2 for very high int values
Matt Ryan created OAK-6164: -- Summary: IOUtils.nextPowerOf2() returns lower power of 2 for very high int values Key: OAK-6164 URL: https://issues.apache.org/jira/browse/OAK-6164 Project: Jackrabbit Oak Issue Type: Bug Reporter: Matt Ryan Priority: Minor In the IOUtils.nextPowerOf2() method, all int values are accepted as input. However, there are valid signed integer values that this method accepts as input, but for which a lower power of 2 value is returned. This occurs for values that are valid signed integer values that are greater than the highest possible power of two value in the signed integer range. Signed integer values have the maximum value of 0x7FFF, but the maximum possible power of two in the signed integer range is 0x4000. (The current implementation incorrectly identifies the maximum possible power of two as 0x3FFF, due to how it is computed by doing integer division of 0x7FFF / 2.) In the current implementation any input in the range of [0x4000, 0x7FFF] is a valid signed integer input, but the method will return 0x3FFF as the next valid max power of 2. Two minor things need to be fixed: * If the input is 0x4000, the return value needs to be 0x4000, instead of 0x3FFF which is not a valid power of 2. * If the input is in the range [0x4001, 0x7FFF] I propose the method should instead throw an IllegalArgumentException and indicate that it is not possible to compute a next power of 2 for a number in that range. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (OAK-6159) BlobReferenceIterator: improve test coverage for RDB
[ https://issues.apache.org/jira/browse/OAK-6159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15994853#comment-15994853 ] Julian Reschke edited comment on OAK-6159 at 5/3/17 7:45 PM: - trunk: [r1793644|http://svn.apache.org/r1793644] 1.6: [r1793648|http://svn.apache.org/r1793648] 1.4: [r1793664|http://svn.apache.org/r1793664] 1.2: [r1793697|http://svn.apache.org/r1793697] 1.0: [r1793700|http://svn.apache.org/r1793700] was (Author: reschke): trunk: [r1793644|http://svn.apache.org/r1793644] 1.6: [r1793648|http://svn.apache.org/r1793648] 1.4: [r1793664|http://svn.apache.org/r1793664] 1.2: [r1793697|http://svn.apache.org/r1793697] > BlobReferenceIterator: improve test coverage for RDB > > > Key: OAK-6159 > URL: https://issues.apache.org/jira/browse/OAK-6159 > Project: Jackrabbit Oak > Issue Type: Task > Components: documentmk >Reporter: Julian Reschke >Assignee: Julian Reschke > Fix For: 1.7.0, 1.8, 1.6.2, 1.0.39, 1.4.16, 1.2.26 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (OAK-6159) BlobReferenceIterator: improve test coverage for RDB
[ https://issues.apache.org/jira/browse/OAK-6159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-6159: Fix Version/s: 1.0.39 > BlobReferenceIterator: improve test coverage for RDB > > > Key: OAK-6159 > URL: https://issues.apache.org/jira/browse/OAK-6159 > Project: Jackrabbit Oak > Issue Type: Task > Components: documentmk >Reporter: Julian Reschke >Assignee: Julian Reschke > Fix For: 1.7.0, 1.8, 1.6.2, 1.0.39, 1.4.16, 1.2.26 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (OAK-6159) BlobReferenceIterator: improve test coverage for RDB
[ https://issues.apache.org/jira/browse/OAK-6159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-6159: Labels: (was: candidate_oak_1_0) > BlobReferenceIterator: improve test coverage for RDB > > > Key: OAK-6159 > URL: https://issues.apache.org/jira/browse/OAK-6159 > Project: Jackrabbit Oak > Issue Type: Task > Components: documentmk >Reporter: Julian Reschke >Assignee: Julian Reschke > Fix For: 1.7.0, 1.8, 1.6.2, 1.0.39, 1.4.16, 1.2.26 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (OAK-6163) Add unit test coverage for IOUtils.writeInt/writeLong and IOUtils.readInt/readLong
[ https://issues.apache.org/jira/browse/OAK-6163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Ryan updated OAK-6163: --- Attachment: OAK-6163.1.patch Attached patch file that adds unit tests to cover IOUtils.writeInt(), IOUtils.writeLong(), IOUtils.readInt(), and IOUtils.writeLong(). > Add unit test coverage for IOUtils.writeInt/writeLong and > IOUtils.readInt/readLong > -- > > Key: OAK-6163 > URL: https://issues.apache.org/jira/browse/OAK-6163 > Project: Jackrabbit Oak > Issue Type: Test > Components: commons >Reporter: Matt Ryan >Priority: Minor > Labels: easyfix, patch, test > Attachments: OAK-6163.1.patch > > > There is no unit test coverage for IOUtils.writeInt(), IOUtils.writeLong(), > IOUtils.readInt(), and IOUtils.readLong() in oak-commons. > I am working on a patch and will have one to submit shortly. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (OAK-6163) Add unit test coverage for IOUtils.writeInt/writeLong and IOUtils.readInt/readLong
Matt Ryan created OAK-6163: -- Summary: Add unit test coverage for IOUtils.writeInt/writeLong and IOUtils.readInt/readLong Key: OAK-6163 URL: https://issues.apache.org/jira/browse/OAK-6163 Project: Jackrabbit Oak Issue Type: Test Components: commons Reporter: Matt Ryan Priority: Minor There is no unit test coverage for IOUtils.writeInt(), IOUtils.writeLong(), IOUtils.readInt(), and IOUtils.readLong() in oak-commons. I am working on a patch and will have one to submit shortly. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (OAK-6159) BlobReferenceIterator: improve test coverage for RDB
[ https://issues.apache.org/jira/browse/OAK-6159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15994853#comment-15994853 ] Julian Reschke edited comment on OAK-6159 at 5/3/17 6:56 PM: - trunk: [r1793644|http://svn.apache.org/r1793644] 1.6: [r1793648|http://svn.apache.org/r1793648] 1.4: [r1793664|http://svn.apache.org/r1793664] 1.2: [r1793697|http://svn.apache.org/r1793697] was (Author: reschke): trunk: [r1793644|http://svn.apache.org/r1793644] 1.6: [r1793648|http://svn.apache.org/r1793648] 1.4: [r1793664|http://svn.apache.org/r1793664] > BlobReferenceIterator: improve test coverage for RDB > > > Key: OAK-6159 > URL: https://issues.apache.org/jira/browse/OAK-6159 > Project: Jackrabbit Oak > Issue Type: Task > Components: documentmk >Reporter: Julian Reschke >Assignee: Julian Reschke > Labels: candidate_oak_1_0 > Fix For: 1.7.0, 1.8, 1.6.2, 1.4.16, 1.2.26 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (OAK-6159) BlobReferenceIterator: improve test coverage for RDB
[ https://issues.apache.org/jira/browse/OAK-6159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-6159: Labels: candidate_oak_1_0 (was: candidate_oak_1_0 candidate_oak_1_2) > BlobReferenceIterator: improve test coverage for RDB > > > Key: OAK-6159 > URL: https://issues.apache.org/jira/browse/OAK-6159 > Project: Jackrabbit Oak > Issue Type: Task > Components: documentmk >Reporter: Julian Reschke >Assignee: Julian Reschke > Labels: candidate_oak_1_0 > Fix For: 1.7.0, 1.8, 1.6.2, 1.4.16, 1.2.26 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (OAK-6159) BlobReferenceIterator: improve test coverage for RDB
[ https://issues.apache.org/jira/browse/OAK-6159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-6159: Fix Version/s: 1.2.26 > BlobReferenceIterator: improve test coverage for RDB > > > Key: OAK-6159 > URL: https://issues.apache.org/jira/browse/OAK-6159 > Project: Jackrabbit Oak > Issue Type: Task > Components: documentmk >Reporter: Julian Reschke >Assignee: Julian Reschke > Labels: candidate_oak_1_0 > Fix For: 1.7.0, 1.8, 1.6.2, 1.4.16, 1.2.26 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (OAK-5999) Document Configuration of FileBlobStore
[
https://issues.apache.org/jira/browse/OAK-5999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15995162#comment-15995162
]
Konrad Windszus commented on OAK-5999:
--
It seems that FileBlobStore is really not yet production ready, if I interpret
the comment in
https://github.com/apache/jackrabbit-oak/blob/2acda3156cfad9993310e7aa0492cdc0b65aa5f7/oak-blob/src/main/java/org/apache/jackrabbit/oak/spi/blob/FileBlobStore.java#L56
correctly.
> Document Configuration of FileBlobStore
> ---
>
> Key: OAK-5999
> URL: https://issues.apache.org/jira/browse/OAK-5999
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: blob
>Reporter: Konrad Windszus
>
> Although according to
> http://jackrabbit.apache.org/oak/docs/plugins/blobstore.html the
> {{FileBlobStore}} should have some advantages over {{DataStores}}, its
> configuration is not documented in
> http://jackrabbit.apache.org/oak/docs/osgi_config.html. Also there was an
> unanswered request regarding actual usage of it in
> http://oak.markmail.org/message/ip24gzbgdyzy7jf7?q=fileblobstore.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (OAK-6159) BlobReferenceIterator: improve test coverage for RDB
[ https://issues.apache.org/jira/browse/OAK-6159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15994853#comment-15994853 ] Julian Reschke edited comment on OAK-6159 at 5/3/17 3:33 PM: - trunk: [r1793644|http://svn.apache.org/r1793644] 1.6: [r1793648|http://svn.apache.org/r1793648] 1.4: [r1793664|http://svn.apache.org/r1793664] was (Author: reschke): trunk: [r1793644|http://svn.apache.org/r1793644] 1.6: [r1793648|http://svn.apache.org/r1793648] > BlobReferenceIterator: improve test coverage for RDB > > > Key: OAK-6159 > URL: https://issues.apache.org/jira/browse/OAK-6159 > Project: Jackrabbit Oak > Issue Type: Task > Components: documentmk >Reporter: Julian Reschke >Assignee: Julian Reschke > Labels: candidate_oak_1_0, candidate_oak_1_2 > Fix For: 1.7.0, 1.8, 1.6.2, 1.4.16 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (OAK-6162) BlobReferenceIterator refactoring
[
https://issues.apache.org/jira/browse/OAK-6162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-6162:
Attachment: OAK-6162.diff
updated patch
> BlobReferenceIterator refactoring
> -
>
> Key: OAK-6162
> URL: https://issues.apache.org/jira/browse/OAK-6162
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: documentmk
>Reporter: Julian Reschke
>Assignee: Julian Reschke
> Fix For: 1.8
>
> Attachments: OAK-6162.diff, OAK-6162.diff
>
>
> - generic iterator should use {{Utils.getSelectedDocuments()}} to obtain
> iterator
> - {{MongoBlobReferenceIterator}} should just extend
> {{BlobReferenceIterator}}, using its own iterator
> - {{Utils.getSelectedDocuments()}} should allow specifying the batch size
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (OAK-6159) BlobReferenceIterator: improve test coverage for RDB
[ https://issues.apache.org/jira/browse/OAK-6159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-6159: Fix Version/s: 1.4.16 > BlobReferenceIterator: improve test coverage for RDB > > > Key: OAK-6159 > URL: https://issues.apache.org/jira/browse/OAK-6159 > Project: Jackrabbit Oak > Issue Type: Task > Components: documentmk >Reporter: Julian Reschke >Assignee: Julian Reschke > Labels: candidate_oak_1_0, candidate_oak_1_2 > Fix For: 1.7.0, 1.8, 1.6.2, 1.4.16 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (OAK-6159) BlobReferenceIterator: improve test coverage for RDB
[ https://issues.apache.org/jira/browse/OAK-6159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-6159: Labels: candidate_oak_1_0 candidate_oak_1_2 (was: candidate_oak_1_0 candidate_oak_1_2 candidate_oak_1_4) > BlobReferenceIterator: improve test coverage for RDB > > > Key: OAK-6159 > URL: https://issues.apache.org/jira/browse/OAK-6159 > Project: Jackrabbit Oak > Issue Type: Task > Components: documentmk >Reporter: Julian Reschke >Assignee: Julian Reschke > Labels: candidate_oak_1_0, candidate_oak_1_2 > Fix For: 1.7.0, 1.8, 1.6.2, 1.4.16 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (OAK-3712) Clean up uncommitted changes
[ https://issues.apache.org/jira/browse/OAK-3712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-3712: -- Summary: Clean up uncommitted changes (was: Clean up old and uncommitted changes) Changed the summary of this issue. The implementation now ensures uncommitted changes are eventually removed and maintains a sweep revision marker that indicates up to which revision it is safe to assume a change is committed. > Clean up uncommitted changes > > > Key: OAK-3712 > URL: https://issues.apache.org/jira/browse/OAK-3712 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: core, documentmk >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger > Fix For: 1.8 > > Attachments: > org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreSweepTest.txt, > TEST-org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreSweepTest.xml, > unit-tests.log > > > Clean up old and uncommitted changes in the main document. This issue is > related to OAK-2392, which is specifically about changes on binary properties > and effect on blob GC. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (OAK-5707) [Oak lucene indexes] Clarify aggregates, nodeScopeIndex, propertyIndex, analyzed
[ https://issues.apache.org/jira/browse/OAK-5707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated OAK-5707: Component/s: lucene doc > [Oak lucene indexes] Clarify aggregates, nodeScopeIndex, propertyIndex, > analyzed > > > Key: OAK-5707 > URL: https://issues.apache.org/jira/browse/OAK-5707 > Project: Jackrabbit Oak > Issue Type: Documentation > Components: doc, lucene >Reporter: David Gonzalez >Assignee: Vikas Saurabh > Attachments: OAK-5707.patch, OAK-5707-v2-WIP.patch > > > Oak lucene documentation would benefit from clarifying the relationships and > expect behaviors around aggregates, nodeScopeIndex, propertyIndex and > analyzed. > These features have some overlap in what they do and/or augment one another, > but to the lay-developer it is unclear how these work in concern and/or the > implications of these using the various features. > Its worth remembering many developers are under the mindset (shifting from > jackrabbit 2 -> oak) that oak indexing requires explicit inclusion of content > into search results; thus implicit content inclusion into indexes via > generalized aggregations (vs named properties) is unclear/unexpected to many. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (OAK-3711) Clean up _revision entries on commit root documents
[ https://issues.apache.org/jira/browse/OAK-3711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved OAK-3711. --- Resolution: Fixed Fix Version/s: 1.7.0 Resolving this issue. The feature is implemented. > Clean up _revision entries on commit root documents > --- > > Key: OAK-3711 > URL: https://issues.apache.org/jira/browse/OAK-3711 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: documentmk >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger > Fix For: 1.7.0, 1.8 > > > The _revisions entries on commit root documents are currently not cleaned up > and accumulate in split documents. > One possible solution may be to ensure that there are no uncommitted changes > up to certain revisions. Older revisions would then be considered valid and > commit information on the commit root document wouldn't be needed anymore. > For regular commits this is probably not that difficult. However, changes > from branch commits require the merge revision set in the commit entry on the > commit root to decide when those changes were made visible to other sessions. > A simple solution could be to rewrite such changes with the merge revision. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (OAK-5858) Lucene index may return the wrong result if path is excluded
[
https://issues.apache.org/jira/browse/OAK-5858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated OAK-5858:
Component/s: lucene
> Lucene index may return the wrong result if path is excluded
>
>
> Key: OAK-5858
> URL: https://issues.apache.org/jira/browse/OAK-5858
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Thomas Mueller
> Fix For: 1.8
>
>
> If a query uses a Lucene index that has "excludedPaths", the query result may
> be wrong (not contain all matching nodes). This is case even if there is a
> property index available for the queried property. Example:
> {noformat}
> Indexes:
> /oak:index/resourceType/type = "property"
> /oak:index/lucene/type = "lucene"
> /oak:index/lucene/excludedPaths = ["/etc"]
> /oak:index/lucene/indexRules/nt:base/properties/resourceType
> Query:
> /jcr:root/etc//*[jcr:like(@resourceType, "x%y")]
> Index cost:
> cost for /oak:index/resourceType is 1602.0
> cost for /oak:index/lucene is 1001.0
> Result:
> (empty)
> Expected result:
> /etc/a
> /etc/b
> {noformat}
> Here, the lucene index is picked, even thought the query explicitly queries
> for /etc, and the lucene index has this path excluded.
> I think the lucene index should not be picked in case the index does not
> match the query path.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (OAK-5706) Function based indexes with "like" conditions
[
https://issues.apache.org/jira/browse/OAK-5706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated OAK-5706:
Component/s: indexing
> Function based indexes with "like" conditions
> -
>
> Key: OAK-5706
> URL: https://issues.apache.org/jira/browse/OAK-5706
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: indexing
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
> Fix For: 1.8
>
>
> Currently, a function-based index is not used when using "like" conditions,
> as follows:
> {noformat}
> /jcr:root//*[jcr:like(fn:lower-case(fn:name()), 'abc%')]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (OAK-5999) Document Configuration of FileBlobStore
[
https://issues.apache.org/jira/browse/OAK-5999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated OAK-5999:
Component/s: blob
> Document Configuration of FileBlobStore
> ---
>
> Key: OAK-5999
> URL: https://issues.apache.org/jira/browse/OAK-5999
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: blob
>Reporter: Konrad Windszus
>
> Although according to
> http://jackrabbit.apache.org/oak/docs/plugins/blobstore.html the
> {{FileBlobStore}} should have some advantages over {{DataStores}}, its
> configuration is not documented in
> http://jackrabbit.apache.org/oak/docs/osgi_config.html. Also there was an
> unanswered request regarding actual usage of it in
> http://oak.markmail.org/message/ip24gzbgdyzy7jf7?q=fileblobstore.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (OAK-5833) Intermediate commits during (re-)indexing of synchronous index
[ https://issues.apache.org/jira/browse/OAK-5833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated OAK-5833: Component/s: indexing > Intermediate commits during (re-)indexing of synchronous index > -- > > Key: OAK-5833 > URL: https://issues.apache.org/jira/browse/OAK-5833 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: indexing >Reporter: Thomas Mueller >Assignee: Thomas Mueller > Fix For: 1.8 > > Attachments: NodeTraverser.java, SplitRepositoryEvenly.java > > > Like OAK-2556, we should also support easier reindexing for synchronous > indexes. See also this [discussion > thread|https://lists.apache.org/thread.html/3b30afce33d84e7c3a82cf49efc0c65bfc33db4b429d50df1e05fae7@%3Coak-dev.jackrabbit.apache.org%3E]. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (OAK-6162) BlobReferenceIterator refactoring
[
https://issues.apache.org/jira/browse/OAK-6162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15995056#comment-15995056
]
Julian Reschke edited comment on OAK-6162 at 5/3/17 3:22 PM:
-
[~chetanm], [~mreutegg] - feedback appreciated... Note that the generic ode is
now based on the logic previously used in the mongo specific variant.
was (Author: reschke):
[~chetanm], [~mreutegg] - feedback appreciated...
> BlobReferenceIterator refactoring
> -
>
> Key: OAK-6162
> URL: https://issues.apache.org/jira/browse/OAK-6162
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: documentmk
>Reporter: Julian Reschke
>Assignee: Julian Reschke
> Fix For: 1.8
>
> Attachments: OAK-6162.diff
>
>
> - generic iterator should use {{Utils.getSelectedDocuments()}} to obtain
> iterator
> - {{MongoBlobReferenceIterator}} should just extend
> {{BlobReferenceIterator}}, using its own iterator
> - {{Utils.getSelectedDocuments()}} should allow specifying the batch size
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (OAK-6162) BlobReferenceIterator refactoring
[
https://issues.apache.org/jira/browse/OAK-6162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-6162:
Attachment: OAK-6162.diff
[~chetanm], [~mreutegg] - feedback appreciated...
> BlobReferenceIterator refactoring
> -
>
> Key: OAK-6162
> URL: https://issues.apache.org/jira/browse/OAK-6162
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: documentmk
>Reporter: Julian Reschke
>Assignee: Julian Reschke
> Fix For: 1.8
>
> Attachments: OAK-6162.diff
>
>
> - generic iterator should use {{Utils.getSelectedDocuments()}} to obtain
> iterator
> - {{MongoBlobReferenceIterator}} should just extend
> {{BlobReferenceIterator}}, using its own iterator
> - {{Utils.getSelectedDocuments()}} should allow specifying the batch size
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-6138) Remove addObserver method from Scheduler API
[
https://issues.apache.org/jira/browse/OAK-6138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15995045#comment-15995045
]
Michael Dürig commented on OAK-6138:
I kinda like this, but I leave it to you whether you prefer this variant over
the other.
Just one thing on the side (as we are now on Java 8), we could do away with
that {{NOOP}} {{Closeable}} and just replace it with {{return () -> {};}}.
> Remove addObserver method from Scheduler API
>
>
> Key: OAK-6138
> URL: https://issues.apache.org/jira/browse/OAK-6138
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: segment-tar
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Minor
> Fix For: 1.8, 1.7.3
>
> Attachments: OAK-6138-02.patch, OAK-6138.patch
>
>
> We should remove the {{addObserver()}} method from the {{Scheduler}}
> interface and instead have {{LockBasedScheduler}} implement {{Observable}}(or
> not depending on the {{dispatchChanges}} flag in
> {{LockBasedSchedulerBuilder.build()}}. {{SegmentNodeStore.addObserver()}}
> would then instance of check the scheduler for {{Observable}}.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (OAK-6138) Remove addObserver method from Scheduler API
[
https://issues.apache.org/jira/browse/OAK-6138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu updated OAK-6138:
-
Attachment: OAK-6138-02.patch
[~mduerig], I followed your suggestion regarding having an
{{ObsevableLockBasedScheduler}} which gets instantiated in the builder based on
{{dispatchChanges}} flag.
Could you take a look at the latest patch, please?
> Remove addObserver method from Scheduler API
>
>
> Key: OAK-6138
> URL: https://issues.apache.org/jira/browse/OAK-6138
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: segment-tar
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Minor
> Fix For: 1.8, 1.7.3
>
> Attachments: OAK-6138-02.patch, OAK-6138.patch
>
>
> We should remove the {{addObserver()}} method from the {{Scheduler}}
> interface and instead have {{LockBasedScheduler}} implement {{Observable}}(or
> not depending on the {{dispatchChanges}} flag in
> {{LockBasedSchedulerBuilder.build()}}. {{SegmentNodeStore.addObserver()}}
> would then instance of check the scheduler for {{Observable}}.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-6150) Javadoc plugin fails on Java 8
[
https://issues.apache.org/jira/browse/OAK-6150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15994994#comment-15994994
]
angela commented on OAK-6150:
-
fixed {{OakValue}} at revision 1793657.
> Javadoc plugin fails on Java 8
> --
>
> Key: OAK-6150
> URL: https://issues.apache.org/jira/browse/OAK-6150
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: doc
>Reporter: Alex Parvulescu
>Assignee: Alex Parvulescu
>Priority: Blocker
> Fix For: 1.7.0
>
>
> As discussed on the mailing list (will provide link soon) the javadoc
> generation fails on java 8. For next level complexity the release plugin also
> fails.
> For javadocs:
> {noformat}
> mvn javadoc:javadoc
> {noformat}
> and for the more adventurous:
> {noformat}
> mvn release:prepare -DdryRun=true
> {noformat}
> I'm tentatively setting fix version 1.7.0 to try to resolve this in time for
> the release (not sure when that is though).
> [~reschke] could you add the relevant errors here?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (OAK-6162) BlobReferenceIterator refactoring
Julian Reschke created OAK-6162:
---
Summary: BlobReferenceIterator refactoring
Key: OAK-6162
URL: https://issues.apache.org/jira/browse/OAK-6162
Project: Jackrabbit Oak
Issue Type: Task
Components: documentmk
Reporter: Julian Reschke
Assignee: Julian Reschke
Fix For: 1.8
- generic iterator should use {{Utils.getSelectedDocuments()}} to obtain
iterator
- {{MongoBlobReferenceIterator}} should just extend {{BlobReferenceIterator}},
using its own iterator
- {{Utils.getSelectedDocuments()}} should allow specifying the batch size
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-3710) Continuous revision GC
[
https://issues.apache.org/jira/browse/OAK-3710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15994975#comment-15994975
]
Marcel Reutegger commented on OAK-3710:
---
A first 'implementation' is available using oak-run with the {{revisions}} mode
and the {{collect}} command. It now supports a {{--continuous}} option. When
enabled, the {{collect}} command will run continuously, but no more frequent
than once every five seconds. This is the resolution of the {{_modified}} field
used for Revision GC.
> Continuous revision GC
> --
>
> Key: OAK-3710
> URL: https://issues.apache.org/jira/browse/OAK-3710
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: documentmk
>Reporter: Marcel Reutegger
>
> Implement continuous revision GC cleaning up documents older than a given
> threshold (e.g. one day). This issue is related to OAK-3070 where each GC run
> starts where the last one finished.
> This will avoid peak load on the system as we see it right now, when GC is
> triggered once a day.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-6161) Continuous flag for revisions collect command
[
https://issues.apache.org/jira/browse/OAK-6161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15994970#comment-15994970
]
Marcel Reutegger commented on OAK-6161:
---
Updated documentation: http://svn.apache.org/r1793653
> Continuous flag for revisions collect command
> -
>
> Key: OAK-6161
> URL: https://issues.apache.org/jira/browse/OAK-6161
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: run
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
>Priority: Minor
> Fix For: 1.7.0, 1.8
>
>
> Add a {{--continuous}} flag to the {{revisions}} mode, instructing the
> {{collect}} command to run continuously.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (OAK-6161) Continuous flag for revisions collect command
[
https://issues.apache.org/jira/browse/OAK-6161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger resolved OAK-6161.
---
Resolution: Fixed
Fix Version/s: 1.7.0
Implemented in trunk: http://svn.apache.org/r1793651
> Continuous flag for revisions collect command
> -
>
> Key: OAK-6161
> URL: https://issues.apache.org/jira/browse/OAK-6161
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: run
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
>Priority: Minor
> Fix For: 1.7.0, 1.8
>
>
> Add a {{--continuous}} flag to the {{revisions}} mode, instructing the
> {{collect}} command to run continuously.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (OAK-6161) Continuous flag for revisions collect command
Marcel Reutegger created OAK-6161:
-
Summary: Continuous flag for revisions collect command
Key: OAK-6161
URL: https://issues.apache.org/jira/browse/OAK-6161
Project: Jackrabbit Oak
Issue Type: New Feature
Components: run
Reporter: Marcel Reutegger
Assignee: Marcel Reutegger
Priority: Minor
Fix For: 1.8
Add a {{--continuous}} flag to the {{revisions}} mode, instructing the
{{collect}} command to run continuously.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (OAK-6159) BlobReferenceIterator: improve test coverage for RDB
[ https://issues.apache.org/jira/browse/OAK-6159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15994853#comment-15994853 ] Julian Reschke edited comment on OAK-6159 at 5/3/17 2:11 PM: - trunk: [r1793644|http://svn.apache.org/r1793644] 1.6: [r1793648|http://svn.apache.org/r1793648] was (Author: reschke): trunk: [r1793644|http://svn.apache.org/r1793644] > BlobReferenceIterator: improve test coverage for RDB > > > Key: OAK-6159 > URL: https://issues.apache.org/jira/browse/OAK-6159 > Project: Jackrabbit Oak > Issue Type: Task > Components: documentmk >Reporter: Julian Reschke >Assignee: Julian Reschke > Labels: candidate_oak_1_0, candidate_oak_1_2, candidate_oak_1_4 > Fix For: 1.7.0, 1.8, 1.6.2 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (OAK-6159) BlobReferenceIterator: improve test coverage for RDB
[ https://issues.apache.org/jira/browse/OAK-6159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-6159: Fix Version/s: 1.6.2 > BlobReferenceIterator: improve test coverage for RDB > > > Key: OAK-6159 > URL: https://issues.apache.org/jira/browse/OAK-6159 > Project: Jackrabbit Oak > Issue Type: Task > Components: documentmk >Reporter: Julian Reschke >Assignee: Julian Reschke > Labels: candidate_oak_1_0, candidate_oak_1_2, candidate_oak_1_4 > Fix For: 1.7.0, 1.8, 1.6.2 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (OAK-6159) BlobReferenceIterator: improve test coverage for RDB
[ https://issues.apache.org/jira/browse/OAK-6159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-6159: Labels: candidate_oak_1_0 candidate_oak_1_2 candidate_oak_1_4 (was: candidate_oak_1_0 candidate_oak_1_2 candidate_oak_1_4 candidate_oak_1_6) > BlobReferenceIterator: improve test coverage for RDB > > > Key: OAK-6159 > URL: https://issues.apache.org/jira/browse/OAK-6159 > Project: Jackrabbit Oak > Issue Type: Task > Components: documentmk >Reporter: Julian Reschke >Assignee: Julian Reschke > Labels: candidate_oak_1_0, candidate_oak_1_2, candidate_oak_1_4 > Fix For: 1.7.0, 1.8, 1.6.2 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (OAK-5519) Skip problematic binaries instead of blocking indexing
[ https://issues.apache.org/jira/browse/OAK-5519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller updated OAK-5519: Fix Version/s: 1.8 > Skip problematic binaries instead of blocking indexing > -- > > Key: OAK-5519 > URL: https://issues.apache.org/jira/browse/OAK-5519 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: indexing >Reporter: Alexander Klimetschek > Labels: resilience > Fix For: 1.8 > > > If a text extraction is blocked (weird PDF) or a blob cannot be found in the > datastore or any other error upon indexing one item from the repository that > is outside the scope of the indexer, it currently halts the indexing (lane). > Thus one item (that maybe isn't important to the users at all) can block the > indexing of other, new content (that might be important to users), and it > always requires manual intervention (which is also not easy and requires oak > experts). > Instead, the item could be remembered in a known issue list, proper warnings > given, and indexing continue. Maintenance operations should be available to > come back to reindex these, or the indexer could automatically retry after > some time. This would allow normal user activity to go on without manual > intervention, and solving the problem (if it's isolated to some binaries) can > be deferred. > I think the line should probably be drawn for binary properties. Not sure if > other JCR property types could trigger a similar issue, and if a failure in > them might actually warrant a halt, as it could lead to an "incorrect" index, > if these properties are important. But maybe the line is simply a try & catch > around "full text extraction". -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (OAK-5947) Allowing non-admin user to set repository permissions fails
[
https://issues.apache.org/jira/browse/OAK-5947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela resolved OAK-5947.
-
Resolution: Fixed
Fix Version/s: 1.7.0
Committed revision 1793646.
> Allowing non-admin user to set repository permissions fails
> ---
>
> Key: OAK-5947
> URL: https://issues.apache.org/jira/browse/OAK-5947
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.0, 1.2, 1.4.0, 1.6.0
>Reporter: Julian Sedding
>Assignee: angela
> Fix For: 1.7.0, 1.8
>
> Attachments: OAK-5947.patch, OAK-5947-tests.patch,
> SetRepoPolicyTest.patch
>
>
> Given a user principal {{testUser}} is granted {{jcr:readAccessControl}} and
> {{jcr:modifyAccessControl}} on the repository ({{rep:repoPolicy}}), I would
> expect that this user can e.g. allow {{everyone}} the
> {{jcr:namespaceManagement}} permission on the repository.
> Currently this fails with the following exception:
> {noformat}
> javax.jcr.PathNotFoundException: No tree at null
> at
> org.apache.jackrabbit.oak.spi.security.authorization.accesscontrol.AbstractAccessControlManager.getTree(AbstractAccessControlManager.java:163)
> at
> org.apache.jackrabbit.oak.security.authorization.accesscontrol.AccessControlManagerImpl.getApplicablePolicies(AccessControlManagerImpl.java:184)
> at
> org.apache.jackrabbit.oak.jcr.delegate.AccessControlManagerDelegator$7.perform(AccessControlManagerDelegator.java:121)
> at
> org.apache.jackrabbit.oak.jcr.delegate.AccessControlManagerDelegator$7.perform(AccessControlManagerDelegator.java:117)
> at
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.perform(SessionDelegate.java:208)
> at
> org.apache.jackrabbit.oak.jcr.delegate.AccessControlManagerDelegator.getApplicablePolicies(AccessControlManagerDelegator.java:117)
> at
> org.apache.jackrabbit.oak.jcr.delegate.JackrabbitAccessControlManagerDelegator.getApplicablePolicies(JackrabbitAccessControlManagerDelegator.java:147)
> at
> org.apache.jackrabbit.commons.jackrabbit.authorization.AccessControlUtils.getAccessControlList(AccessControlUtils.java:128)
> at
> org.apache.jackrabbit.oak.jcr.SetRepoPolicyPermissionsTest.setRepositoryPermissions(SetRepoPolicyPermissionsTest.java:85)
>
> {noformat}
> or after granting {{jcr:read}} on {{/}}:
> {noformat}
> javax.jcr.AccessDeniedException
> at org.apache.jackrabbit.oak.util.NodeUtil.addChild(NodeUtil.java:113)
> at
> org.apache.jackrabbit.oak.security.authorization.accesscontrol.AccessControlManagerImpl.setNodeBasedAcl(AccessControlManagerImpl.java:289)
> at
> org.apache.jackrabbit.oak.security.authorization.accesscontrol.AccessControlManagerImpl.setPolicy(AccessControlManagerImpl.java:220)
> at
> org.apache.jackrabbit.oak.jcr.delegate.AccessControlManagerDelegator$8.performVoid(AccessControlManagerDelegator.java:132)
> at
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.performVoid(SessionDelegate.java:274)
> at
> org.apache.jackrabbit.oak.jcr.delegate.AccessControlManagerDelegator.setPolicy(AccessControlManagerDelegator.java:129)
> at
> org.apache.jackrabbit.oak.jcr.delegate.JackrabbitAccessControlManagerDelegator.setPolicy(JackrabbitAccessControlManagerDelegator.java:152)
> at
> org.apache.jackrabbit.oak.jcr.SetRepoPolicyPermissionsTest.setRepositoryPermissions(SetRepoPolicyPermissionsTest.java:90)
>
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-6138) Remove addObserver method from Scheduler API
[
https://issues.apache.org/jira/browse/OAK-6138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15994914#comment-15994914
]
Michael Dürig commented on OAK-6138:
Yes this is what I was thinking of. The latter class can probably be a static
private inner class of the former.
> Remove addObserver method from Scheduler API
>
>
> Key: OAK-6138
> URL: https://issues.apache.org/jira/browse/OAK-6138
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: segment-tar
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Minor
> Fix For: 1.8, 1.7.3
>
> Attachments: OAK-6138.patch
>
>
> We should remove the {{addObserver()}} method from the {{Scheduler}}
> interface and instead have {{LockBasedScheduler}} implement {{Observable}}(or
> not depending on the {{dispatchChanges}} flag in
> {{LockBasedSchedulerBuilder.build()}}. {{SegmentNodeStore.addObserver()}}
> would then instance of check the scheduler for {{Observable}}.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (OAK-6158) AccessControlManagerImpl: adding mv-restrictions with principal-based-entry fails
[
https://issues.apache.org/jira/browse/OAK-6158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela resolved OAK-6158.
-
Resolution: Fixed
Assignee: angela
Committed revision 1793645.
> AccessControlManagerImpl: adding mv-restrictions with principal-based-entry
> fails
> -
>
> Key: OAK-6158
> URL: https://issues.apache.org/jira/browse/OAK-6158
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Reporter: angela
>Assignee: angela
>Priority: Minor
> Fix For: 1.7.0, 1.8
>
>
> writing back a policy obtained through
> {{JackrabbitAccessControlManager.getPolicies(Principal)}} will fail if an
> entry contains mv-restrictions.
> spotted while working on OAK-5882.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (OAK-6160) PrincipalAcl.equals doesn't include principal
[ https://issues.apache.org/jira/browse/OAK-6160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela resolved OAK-6160. - Resolution: Fixed Committed revision 1793645. > PrincipalAcl.equals doesn't include principal > - > > Key: OAK-6160 > URL: https://issues.apache.org/jira/browse/OAK-6160 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Reporter: angela >Assignee: angela >Priority: Minor > Fix For: 1.7.0, 1.8 > > > spotted while working on OAK-5882 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (OAK-6155) AccessControlManagerImpl: removing entries through principal-set-acl fails
[
https://issues.apache.org/jira/browse/OAK-6155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela resolved OAK-6155.
-
Resolution: Fixed
Committed revision 1793645.
> AccessControlManagerImpl: removing entries through principal-set-acl fails
> --
>
> Key: OAK-6155
> URL: https://issues.apache.org/jira/browse/OAK-6155
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Reporter: angela
>Assignee: angela
>Priority: Minor
> Fix For: 1.7.0, 1.8
>
>
> writing back a policy obtained through
> {{AccessControlManager.getPolicies(Principal)}} will fail with
> {{AccessControlException}} if removal of existing entries is involved. Reason
> for the failure is that the entries in that policy have an additional
> node-path restr set in order to be able to track their origin and thus will
> not match the real entry bound to the resource-based policy.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-6150) Javadoc plugin fails on Java 8
[
https://issues.apache.org/jira/browse/OAK-6150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15994867#comment-15994867
]
Alex Parvulescu commented on OAK-6150:
--
I assume the following error has the same type of issue as before (the
{{ServiceReference}} class can be imported from a different source when
aggregating javadocs for the global project):
{noformat}
[ERROR]
oak-pojosr/src/main/java/org/apache/jackrabbit/oak/run/osgi/ConfigTracker.java:60:
error: type ServiceReference does not take parameters
[ERROR] public ConfigurationAdmin
addingService(ServiceReference reference) {
{noformat}
> Javadoc plugin fails on Java 8
> --
>
> Key: OAK-6150
> URL: https://issues.apache.org/jira/browse/OAK-6150
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: doc
>Reporter: Alex Parvulescu
>Assignee: Alex Parvulescu
>Priority: Blocker
> Fix For: 1.7.0
>
>
> As discussed on the mailing list (will provide link soon) the javadoc
> generation fails on java 8. For next level complexity the release plugin also
> fails.
> For javadocs:
> {noformat}
> mvn javadoc:javadoc
> {noformat}
> and for the more adventurous:
> {noformat}
> mvn release:prepare -DdryRun=true
> {noformat}
> I'm tentatively setting fix version 1.7.0 to try to resolve this in time for
> the release (not sure when that is though).
> [~reschke] could you add the relevant errors here?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-6159) BlobReferenceIterator: improve test coverage for RDB
[ https://issues.apache.org/jira/browse/OAK-6159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15994853#comment-15994853 ] Julian Reschke commented on OAK-6159: - trunk: [r1793644|http://svn.apache.org/r1793644] > BlobReferenceIterator: improve test coverage for RDB > > > Key: OAK-6159 > URL: https://issues.apache.org/jira/browse/OAK-6159 > Project: Jackrabbit Oak > Issue Type: Task > Components: documentmk >Reporter: Julian Reschke >Assignee: Julian Reschke > Labels: candidate_oak_1_0, candidate_oak_1_2, candidate_oak_1_4, > candidate_oak_1_6 > Fix For: 1.7.0, 1.8 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (OAK-6136) Extract the multiplexing implementation code into a separate bundle
[ https://issues.apache.org/jira/browse/OAK-6136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15994851#comment-15994851 ] Tomek Rękawek commented on OAK-6136: Hi [~rombert], first of all - my apologies for not waiting for your vote. I thought that two +1 is enough and didn't see you on IM to ask directly, but I should wait anyway. bq. Federation to me see to be about different services becoming interoperable More importantly I think it's about existing services that work in a standalone fashion but can also work together - in a federated mode. \[...\] In our scenario the mounts - those which we assemble - are not really usable by themselves as they only contain a part of the repository. In our case, the existing service is a node store and each of them has to be a fully functional and working implementation. I think the [federated MySQL|https://dev.mysql.com/doc/refman/5.7/en/federated-description.html] engine is quite similar to what we have: * Federated Table <-> mount list * Remote Server <-> partial node store * Remote Table <-> mounted subtree on the partial node store bq. I think multiplexing is a better metaphor. It originally was about combining multiple signals into a single one. I have no experience with telecommunications so I won't comment on that but for me the concept of combining multiple parts into a larger one is closer to what we offer with our implementation. I think that in case of multiplexing, each partial signal represents a value on its own, is independent from the others and is not meant to be used together with them. On the other hand, the multiplexed signal is just a noise and can't be used directly. The only reason why it exists is that it's easy to transport and store. Before using it, it has to be demultiplexed first - and as a result we get the original, partial signals. So, the MultiplexingNodeStore name suggest that we're providing a way to create a few independent node store instances using the same underlying physical node store (which is an interesting exercise as well and shouldn't be too hard, considering our data model). But our case it's the opposite - we want to use the combined store directly and we don't care much how the data are persisted in the partial stores. That's why I still think the "federated" is a better adjective here. WDYT? > Extract the multiplexing implementation code into a separate bundle > --- > > Key: OAK-6136 > URL: https://issues.apache.org/jira/browse/OAK-6136 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: federated >Reporter: Robert Munteanu >Assignee: Julian Sedding > Fix For: 1.7.0, 1.8 > > Attachments: > 0001-OAK-6136-Extract-the-multiplexing-implementation-cod.patch, > OAK-6136.patch > > > Since we already kicked off the m12n effort for 1.8 it would be good to > separate the multiplexing implementation from oak-core into its own bundle as > well. > I will look into providing a patch for the change. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (OAK-6138) Remove addObserver method from Scheduler API
[
https://issues.apache.org/jira/browse/OAK-6138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15994850#comment-15994850
]
Andrei Dulceanu commented on OAK-6138:
--
bq. Can we go further from here and make {{LockBasedSchedulerBuilder}} return
(non) {{Observable}} instances of {{LockBasedScheduler}}...
Not sure if I got this right, but are you hinting towards two separate
implementations, such as {{LockBasedScheduler}} and
{{ObservableLockBasedScheduler}}, with the latter extending the former and
adding only {{Observable}} behaviour?
> Remove addObserver method from Scheduler API
>
>
> Key: OAK-6138
> URL: https://issues.apache.org/jira/browse/OAK-6138
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: segment-tar
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Minor
> Fix For: 1.8, 1.7.3
>
> Attachments: OAK-6138.patch
>
>
> We should remove the {{addObserver()}} method from the {{Scheduler}}
> interface and instead have {{LockBasedScheduler}} implement {{Observable}}(or
> not depending on the {{dispatchChanges}} flag in
> {{LockBasedSchedulerBuilder.build()}}. {{SegmentNodeStore.addObserver()}}
> would then instance of check the scheduler for {{Observable}}.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (OAK-6160) PrincipalAcl.equals doesn't include principal
angela created OAK-6160: --- Summary: PrincipalAcl.equals doesn't include principal Key: OAK-6160 URL: https://issues.apache.org/jira/browse/OAK-6160 Project: Jackrabbit Oak Issue Type: Bug Components: core Reporter: angela Assignee: angela Priority: Minor Fix For: 1.7.0, 1.8 spotted while working on OAK-5882 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (OAK-6159) BlobReferenceIterator: improve test coverage for RDB
[ https://issues.apache.org/jira/browse/OAK-6159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke resolved OAK-6159. - Resolution: Fixed Fix Version/s: 1.7.0 > BlobReferenceIterator: improve test coverage for RDB > > > Key: OAK-6159 > URL: https://issues.apache.org/jira/browse/OAK-6159 > Project: Jackrabbit Oak > Issue Type: Task > Components: documentmk >Reporter: Julian Reschke >Assignee: Julian Reschke > Labels: candidate_oak_1_0, candidate_oak_1_2, candidate_oak_1_4, > candidate_oak_1_6 > Fix For: 1.7.0, 1.8 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (OAK-5947) Allowing non-admin user to set repository permissions fails
[
https://issues.apache.org/jira/browse/OAK-5947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15994845#comment-15994845
]
angela commented on OAK-5947:
-
thanks for the review. will adjust the patch accordingly.
> Allowing non-admin user to set repository permissions fails
> ---
>
> Key: OAK-5947
> URL: https://issues.apache.org/jira/browse/OAK-5947
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.0, 1.2, 1.4.0, 1.6.0
>Reporter: Julian Sedding
>Assignee: angela
> Fix For: 1.8
>
> Attachments: OAK-5947.patch, OAK-5947-tests.patch,
> SetRepoPolicyTest.patch
>
>
> Given a user principal {{testUser}} is granted {{jcr:readAccessControl}} and
> {{jcr:modifyAccessControl}} on the repository ({{rep:repoPolicy}}), I would
> expect that this user can e.g. allow {{everyone}} the
> {{jcr:namespaceManagement}} permission on the repository.
> Currently this fails with the following exception:
> {noformat}
> javax.jcr.PathNotFoundException: No tree at null
> at
> org.apache.jackrabbit.oak.spi.security.authorization.accesscontrol.AbstractAccessControlManager.getTree(AbstractAccessControlManager.java:163)
> at
> org.apache.jackrabbit.oak.security.authorization.accesscontrol.AccessControlManagerImpl.getApplicablePolicies(AccessControlManagerImpl.java:184)
> at
> org.apache.jackrabbit.oak.jcr.delegate.AccessControlManagerDelegator$7.perform(AccessControlManagerDelegator.java:121)
> at
> org.apache.jackrabbit.oak.jcr.delegate.AccessControlManagerDelegator$7.perform(AccessControlManagerDelegator.java:117)
> at
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.perform(SessionDelegate.java:208)
> at
> org.apache.jackrabbit.oak.jcr.delegate.AccessControlManagerDelegator.getApplicablePolicies(AccessControlManagerDelegator.java:117)
> at
> org.apache.jackrabbit.oak.jcr.delegate.JackrabbitAccessControlManagerDelegator.getApplicablePolicies(JackrabbitAccessControlManagerDelegator.java:147)
> at
> org.apache.jackrabbit.commons.jackrabbit.authorization.AccessControlUtils.getAccessControlList(AccessControlUtils.java:128)
> at
> org.apache.jackrabbit.oak.jcr.SetRepoPolicyPermissionsTest.setRepositoryPermissions(SetRepoPolicyPermissionsTest.java:85)
>
> {noformat}
> or after granting {{jcr:read}} on {{/}}:
> {noformat}
> javax.jcr.AccessDeniedException
> at org.apache.jackrabbit.oak.util.NodeUtil.addChild(NodeUtil.java:113)
> at
> org.apache.jackrabbit.oak.security.authorization.accesscontrol.AccessControlManagerImpl.setNodeBasedAcl(AccessControlManagerImpl.java:289)
> at
> org.apache.jackrabbit.oak.security.authorization.accesscontrol.AccessControlManagerImpl.setPolicy(AccessControlManagerImpl.java:220)
> at
> org.apache.jackrabbit.oak.jcr.delegate.AccessControlManagerDelegator$8.performVoid(AccessControlManagerDelegator.java:132)
> at
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.performVoid(SessionDelegate.java:274)
> at
> org.apache.jackrabbit.oak.jcr.delegate.AccessControlManagerDelegator.setPolicy(AccessControlManagerDelegator.java:129)
> at
> org.apache.jackrabbit.oak.jcr.delegate.JackrabbitAccessControlManagerDelegator.setPolicy(JackrabbitAccessControlManagerDelegator.java:152)
> at
> org.apache.jackrabbit.oak.jcr.SetRepoPolicyPermissionsTest.setRepositoryPermissions(SetRepoPolicyPermissionsTest.java:90)
>
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (OAK-6159) BlobReferenceIterator: improve test coverage for RDB
[ https://issues.apache.org/jira/browse/OAK-6159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-6159: Labels: candidate_oak_1_0 candidate_oak_1_2 candidate_oak_1_4 candidate_oak_1_6 (was: ) > BlobReferenceIterator: improve test coverage for RDB > > > Key: OAK-6159 > URL: https://issues.apache.org/jira/browse/OAK-6159 > Project: Jackrabbit Oak > Issue Type: Task > Components: documentmk >Reporter: Julian Reschke >Assignee: Julian Reschke > Labels: candidate_oak_1_0, candidate_oak_1_2, candidate_oak_1_4, > candidate_oak_1_6 > Fix For: 1.8 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (OAK-6150) Javadoc plugin fails on Java 8
[
https://issues.apache.org/jira/browse/OAK-6150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15994824#comment-15994824
]
Alex Parvulescu commented on OAK-6150:
--
had a debugging session with [~tmueller] on the first error:
{noformat}
[ERROR]
oak-upgrade/src/main/java/org/apache/jackrabbit/oak/upgrade/RepositoryUpgrade.java:139:
error: cannot find symbol
[ERROR] import org.apache.lucene.index.TermDocs;
[ERROR] ^
[ERROR] symbol: class TermDocs
[ERROR] location: package org.apache.lucene.index
{noformat}
...and it's pretty weird. It's probably related to the fact that oak uses
multiple lucene versions ({{oak-upgrade}} -> {{lucene 3.6.0}}, {{oak-lucene}}
-> {{lucene 4.7.1}}) and the javadocs aggregator gets confused because packages
between the 2 lucene versions don't match. I tried using the
{{excludePackageNames}} option but could not get it to work. Generating
individual javadocs (per module) works fine, but generating from root them
fails because of the aggregation step. Not sure how to fix this yet.
> Javadoc plugin fails on Java 8
> --
>
> Key: OAK-6150
> URL: https://issues.apache.org/jira/browse/OAK-6150
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: doc
>Reporter: Alex Parvulescu
>Assignee: Alex Parvulescu
>Priority: Blocker
> Fix For: 1.7.0
>
>
> As discussed on the mailing list (will provide link soon) the javadoc
> generation fails on java 8. For next level complexity the release plugin also
> fails.
> For javadocs:
> {noformat}
> mvn javadoc:javadoc
> {noformat}
> and for the more adventurous:
> {noformat}
> mvn release:prepare -DdryRun=true
> {noformat}
> I'm tentatively setting fix version 1.7.0 to try to resolve this in time for
> the release (not sure when that is though).
> [~reschke] could you add the relevant errors here?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-6140) Create RDB-specific BlobReferenceIterator
[
https://issues.apache.org/jira/browse/OAK-6140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15994823#comment-15994823
]
Julian Reschke commented on OAK-6140:
-
..had a look at the existing code, and will open separate issues for
refactoring before working on the RDB-specific stuff...
> Create RDB-specific BlobReferenceIterator
> -
>
> Key: OAK-6140
> URL: https://issues.apache.org/jira/browse/OAK-6140
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: rdbmk
>Reporter: Julian Reschke
>Assignee: Julian Reschke
> Fix For: 1.8
>
> Attachments: OAK-6140.diff
>
>
> Mirroring {{MongoBlobReferenceIterator}}, using the capabilities added in
> OAK-5855.
> (might lead to refactoring of {{MongoBlobReferenceIterator}})
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (OAK-6159) BlobReferenceIterator: improve test coverage for RDB
Julian Reschke created OAK-6159: --- Summary: BlobReferenceIterator: improve test coverage for RDB Key: OAK-6159 URL: https://issues.apache.org/jira/browse/OAK-6159 Project: Jackrabbit Oak Issue Type: Task Components: documentmk Reporter: Julian Reschke Assignee: Julian Reschke Fix For: 1.8 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (OAK-6158) AccessControlManagerImpl: adding mv-restrictions with principal-based-entry fails
angela created OAK-6158:
---
Summary: AccessControlManagerImpl: adding mv-restrictions with
principal-based-entry fails
Key: OAK-6158
URL: https://issues.apache.org/jira/browse/OAK-6158
Project: Jackrabbit Oak
Issue Type: Bug
Components: core
Reporter: angela
Priority: Minor
Fix For: 1.7.0, 1.8
writing back a policy obtained through
{{JackrabbitAccessControlManager.getPolicies(Principal)}} will fail if an entry
contains mv-restrictions.
spotted while working on OAK-5882.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (OAK-6140) Create RDB-specific BlobReferenceIterator
[
https://issues.apache.org/jira/browse/OAK-6140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-6140:
Attachment: OAK-6140.diff
(wip)
> Create RDB-specific BlobReferenceIterator
> -
>
> Key: OAK-6140
> URL: https://issues.apache.org/jira/browse/OAK-6140
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: rdbmk
>Reporter: Julian Reschke
>Assignee: Julian Reschke
> Fix For: 1.8
>
> Attachments: OAK-6140.diff
>
>
> Mirroring {{MongoBlobReferenceIterator}}, using the capabilities added in
> OAK-5855.
> (might lead to refactoring of {{MongoBlobReferenceIterator}})
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-5972) Provide a way to abort indexing / reindexing of synchronous indexes
[ https://issues.apache.org/jira/browse/OAK-5972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15994739#comment-15994739 ] Thomas Mueller commented on OAK-5972: - [~chetanm], I think you are right, if we use async indexing for reindexing of synchronous indexes, we don't need that. But I think it would still be nice to be able to abort large commits, I created and linked OAK-6157 to track that (not scheduled currently). > Provide a way to abort indexing / reindexing of synchronous indexes > --- > > Key: OAK-5972 > URL: https://issues.apache.org/jira/browse/OAK-5972 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: query >Reporter: Thomas Mueller > Fix For: 1.8 > > > Indexing and reindexing is slow. There should be a way to abort this (for > example if it was started by accident). -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (OAK-5972) Provide a way to abort indexing / reindexing of synchronous indexes
[ https://issues.apache.org/jira/browse/OAK-5972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller resolved OAK-5972. - Resolution: Won't Fix Resolving won't fix. > Provide a way to abort indexing / reindexing of synchronous indexes > --- > > Key: OAK-5972 > URL: https://issues.apache.org/jira/browse/OAK-5972 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: query >Reporter: Thomas Mueller > Fix For: 1.8 > > > Indexing and reindexing is slow. There should be a way to abort this (for > example if it was started by accident). -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (OAK-6157) Provide a way to abort very large commits
Thomas Mueller created OAK-6157: --- Summary: Provide a way to abort very large commits Key: OAK-6157 URL: https://issues.apache.org/jira/browse/OAK-6157 Project: Jackrabbit Oak Issue Type: New Feature Reporter: Thomas Mueller It would be nice to be able to abort large commits, for example very large remove or move operations (that take many minutes to complete). This is for cases where large operations were triggered by mistake. I don't think we have that ability right now. Possibly we could use a special editor for this that allows to cancel an operation using JMX. For example cancel if the number of changes is larger than x (the ProgressNotificationEditor tracks this). -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (OAK-6150) Javadoc plugin fails on Java 8
[
https://issues.apache.org/jira/browse/OAK-6150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15994723#comment-15994723
]
Alex Parvulescu commented on OAK-6150:
--
ran into this link:
https://cwiki.apache.org/confluence/display/MAVEN/Java+8+Upgrade and apparently
we can use {{-Xdoclint:none}} to temporarily
disable the errors if needed.
> Javadoc plugin fails on Java 8
> --
>
> Key: OAK-6150
> URL: https://issues.apache.org/jira/browse/OAK-6150
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: doc
>Reporter: Alex Parvulescu
>Assignee: Alex Parvulescu
>Priority: Blocker
> Fix For: 1.7.0
>
>
> As discussed on the mailing list (will provide link soon) the javadoc
> generation fails on java 8. For next level complexity the release plugin also
> fails.
> For javadocs:
> {noformat}
> mvn javadoc:javadoc
> {noformat}
> and for the more adventurous:
> {noformat}
> mvn release:prepare -DdryRun=true
> {noformat}
> I'm tentatively setting fix version 1.7.0 to try to resolve this in time for
> the release (not sure when that is though).
> [~reschke] could you add the relevant errors here?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (OAK-6156) Build timeout
[
https://issues.apache.org/jira/browse/OAK-6156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger updated OAK-6156:
--
Summary: Build timeout (was: Build Jackrabbit Oak #241 failed)
> Build timeout
> -
>
> Key: OAK-6156
> URL: https://issues.apache.org/jira/browse/OAK-6156
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: continuous integration
>Reporter: Hudson
>
> Jenkins CI failure: https://builds.apache.org/view/J/job/Jackrabbit%20Oak/
> The build Jackrabbit Oak #241 has failed.
> First failed run: [Jackrabbit Oak
> #241|https://builds.apache.org/job/Jackrabbit%20Oak/241/] [console
> log|https://builds.apache.org/job/Jackrabbit%20Oak/241/console]
> {noformat}
> [INFO] Running org.apache.jackrabbit.oak.plugins.blob.UploadStagingCacheTest
> Build timed out (after 60 minutes). Marking the build as failed.
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (OAK-6156) Build Jackrabbit Oak #241 failed
[
https://issues.apache.org/jira/browse/OAK-6156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger closed OAK-6156.
-
> Build Jackrabbit Oak #241 failed
>
>
> Key: OAK-6156
> URL: https://issues.apache.org/jira/browse/OAK-6156
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: continuous integration
>Reporter: Hudson
>
> Jenkins CI failure: https://builds.apache.org/view/J/job/Jackrabbit%20Oak/
> The build Jackrabbit Oak #241 has failed.
> First failed run: [Jackrabbit Oak
> #241|https://builds.apache.org/job/Jackrabbit%20Oak/241/] [console
> log|https://builds.apache.org/job/Jackrabbit%20Oak/241/console]
> {noformat}
> [INFO] Running org.apache.jackrabbit.oak.plugins.blob.UploadStagingCacheTest
> Build timed out (after 60 minutes). Marking the build as failed.
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (OAK-6156) Build Jackrabbit Oak #241 failed
[
https://issues.apache.org/jira/browse/OAK-6156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger resolved OAK-6156.
---
Resolution: Duplicate
> Build Jackrabbit Oak #241 failed
>
>
> Key: OAK-6156
> URL: https://issues.apache.org/jira/browse/OAK-6156
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: continuous integration
>Reporter: Hudson
>
> Jenkins CI failure: https://builds.apache.org/view/J/job/Jackrabbit%20Oak/
> The build Jackrabbit Oak #241 has failed.
> First failed run: [Jackrabbit Oak
> #241|https://builds.apache.org/job/Jackrabbit%20Oak/241/] [console
> log|https://builds.apache.org/job/Jackrabbit%20Oak/241/console]
> {noformat}
> [INFO] Running org.apache.jackrabbit.oak.plugins.blob.UploadStagingCacheTest
> Build timed out (after 60 minutes). Marking the build as failed.
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (OAK-6156) Build Jackrabbit Oak #241 failed
[
https://issues.apache.org/jira/browse/OAK-6156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger updated OAK-6156:
--
Description:
Jenkins CI failure: https://builds.apache.org/view/J/job/Jackrabbit%20Oak/
The build Jackrabbit Oak #241 has failed.
First failed run: [Jackrabbit Oak
#241|https://builds.apache.org/job/Jackrabbit%20Oak/241/] [console
log|https://builds.apache.org/job/Jackrabbit%20Oak/241/console]
{noformat}
[INFO] Running org.apache.jackrabbit.oak.plugins.blob.UploadStagingCacheTest
Build timed out (after 60 minutes). Marking the build as failed.
{noformat}
was:
Jenkins CI failure: https://builds.apache.org/view/J/job/Jackrabbit%20Oak/
The build Jackrabbit Oak #241 has failed.
First failed run: [Jackrabbit Oak
#241|https://builds.apache.org/job/Jackrabbit%20Oak/241/] [console
log|https://builds.apache.org/job/Jackrabbit%20Oak/241/console]
> Build Jackrabbit Oak #241 failed
>
>
> Key: OAK-6156
> URL: https://issues.apache.org/jira/browse/OAK-6156
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: continuous integration
>Reporter: Hudson
>
> Jenkins CI failure: https://builds.apache.org/view/J/job/Jackrabbit%20Oak/
> The build Jackrabbit Oak #241 has failed.
> First failed run: [Jackrabbit Oak
> #241|https://builds.apache.org/job/Jackrabbit%20Oak/241/] [console
> log|https://builds.apache.org/job/Jackrabbit%20Oak/241/console]
> {noformat}
> [INFO] Running org.apache.jackrabbit.oak.plugins.blob.UploadStagingCacheTest
> Build timed out (after 60 minutes). Marking the build as failed.
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (OAK-6130) Update Oak trunk to Jackrabbit 2.15.2
[ https://issues.apache.org/jira/browse/OAK-6130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-6130: Fix Version/s: 1.8 > Update Oak trunk to Jackrabbit 2.15.2 > - > > Key: OAK-6130 > URL: https://issues.apache.org/jira/browse/OAK-6130 > Project: Jackrabbit Oak > Issue Type: Task > Components: parent >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Fix For: 1.8 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (OAK-6149) AtomicCounter fails with LuceneIndexEditorProvider
[
https://issues.apache.org/jira/browse/OAK-6149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15994719#comment-15994719
]
Davide Giannella commented on OAK-6149:
---
minor note. Maybe we can reuse the
[ExecutorCloser|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-commons/src/main/java/org/apache/jackrabbit/oak/commons/concurrent/ExecutorCloser.java]
for shutting down in the test.
> AtomicCounter fails with LuceneIndexEditorProvider
> --
>
> Key: OAK-6149
> URL: https://issues.apache.org/jira/browse/OAK-6149
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.6.0
> Environment: Oak 1.6.1 with DocumentNodeStore on MongoDB 3.2.x
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
> Fix For: 1.7.0, 1.8, 1.6.2
>
> Attachments: OAK-6149.patch
>
>
> The AtomicCounter fails to consolidate the value when running on
> DocumentNodeStore with lucene indexes.
> The task scheduled by the {{AtomicCounterEditor}} fails with:
> {noformat}
> 02.05.2017 13:42:14.923 *WARN* [atomic-counter-3]
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorProvider No
> CommitContext found for commit
> java.lang.Exception: null
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorProvider.getIndexEditor(LuceneIndexEditorProvider.java:133)
> at
> org.apache.jackrabbit.oak.plugins.index.CompositeIndexEditorProvider.getIndexEditor(CompositeIndexEditorProvider.java:74)
> at
> org.apache.jackrabbit.oak.spi.whiteboard.WhiteboardIndexEditorProvider.getIndexEditor(WhiteboardIndexEditorProvider.java:52)
> at
> org.apache.jackrabbit.oak.plugins.index.IndexUpdate.collectIndexEditors(IndexUpdate.java:240)
> at
> org.apache.jackrabbit.oak.plugins.index.IndexUpdate.enter(IndexUpdate.java:160)
> at
> org.apache.jackrabbit.oak.spi.commit.VisibleEditor.enter(VisibleEditor.java:57)
> at
> org.apache.jackrabbit.oak.spi.commit.CompositeEditor.enter(CompositeEditor.java:66)
> at
> org.apache.jackrabbit.oak.spi.commit.EditorDiff.process(EditorDiff.java:49)
> at
> org.apache.jackrabbit.oak.spi.commit.EditorHook.processCommit(EditorHook.java:54)
> at
> org.apache.jackrabbit.oak.spi.commit.CompositeHook.processCommit(CompositeHook.java:61)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch$InMemory.merge(DocumentNodeStoreBranch.java:511)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch.merge0(DocumentNodeStoreBranch.java:185)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch.merge(DocumentNodeStoreBranch.java:119)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentRootBuilder.merge(DocumentRootBuilder.java:167)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.merge(DocumentNodeStore.java:1694)
> at
> org.apache.jackrabbit.oak.plugins.atomic.AtomicCounterEditor$ConsolidatorTask.call(AtomicCounterEditor.java:410)
> at
> org.apache.jackrabbit.oak.plugins.atomic.AtomicCounterEditor$ConsolidatorTask.call(AtomicCounterEditor.java:335)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (OAK-6156) Build Jackrabbit Oak #241 failed
Hudson created OAK-6156: --- Summary: Build Jackrabbit Oak #241 failed Key: OAK-6156 URL: https://issues.apache.org/jira/browse/OAK-6156 Project: Jackrabbit Oak Issue Type: Bug Components: continuous integration Reporter: Hudson Jenkins CI failure: https://builds.apache.org/view/J/job/Jackrabbit%20Oak/ The build Jackrabbit Oak #241 has failed. First failed run: [Jackrabbit Oak #241|https://builds.apache.org/job/Jackrabbit%20Oak/241/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/241/console] -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (OAK-6149) AtomicCounter fails with LuceneIndexEditorProvider
[
https://issues.apache.org/jira/browse/OAK-6149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger updated OAK-6149:
--
Labels: (was: candidate_oak_1_6)
Fix Version/s: 1.6.2
Merged into 1.6 branch: http://svn.apache.org/r1793638
> AtomicCounter fails with LuceneIndexEditorProvider
> --
>
> Key: OAK-6149
> URL: https://issues.apache.org/jira/browse/OAK-6149
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.6.0
> Environment: Oak 1.6.1 with DocumentNodeStore on MongoDB 3.2.x
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
> Fix For: 1.7.0, 1.8, 1.6.2
>
> Attachments: OAK-6149.patch
>
>
> The AtomicCounter fails to consolidate the value when running on
> DocumentNodeStore with lucene indexes.
> The task scheduled by the {{AtomicCounterEditor}} fails with:
> {noformat}
> 02.05.2017 13:42:14.923 *WARN* [atomic-counter-3]
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorProvider No
> CommitContext found for commit
> java.lang.Exception: null
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorProvider.getIndexEditor(LuceneIndexEditorProvider.java:133)
> at
> org.apache.jackrabbit.oak.plugins.index.CompositeIndexEditorProvider.getIndexEditor(CompositeIndexEditorProvider.java:74)
> at
> org.apache.jackrabbit.oak.spi.whiteboard.WhiteboardIndexEditorProvider.getIndexEditor(WhiteboardIndexEditorProvider.java:52)
> at
> org.apache.jackrabbit.oak.plugins.index.IndexUpdate.collectIndexEditors(IndexUpdate.java:240)
> at
> org.apache.jackrabbit.oak.plugins.index.IndexUpdate.enter(IndexUpdate.java:160)
> at
> org.apache.jackrabbit.oak.spi.commit.VisibleEditor.enter(VisibleEditor.java:57)
> at
> org.apache.jackrabbit.oak.spi.commit.CompositeEditor.enter(CompositeEditor.java:66)
> at
> org.apache.jackrabbit.oak.spi.commit.EditorDiff.process(EditorDiff.java:49)
> at
> org.apache.jackrabbit.oak.spi.commit.EditorHook.processCommit(EditorHook.java:54)
> at
> org.apache.jackrabbit.oak.spi.commit.CompositeHook.processCommit(CompositeHook.java:61)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch$InMemory.merge(DocumentNodeStoreBranch.java:511)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch.merge0(DocumentNodeStoreBranch.java:185)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch.merge(DocumentNodeStoreBranch.java:119)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentRootBuilder.merge(DocumentRootBuilder.java:167)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.merge(DocumentNodeStore.java:1694)
> at
> org.apache.jackrabbit.oak.plugins.atomic.AtomicCounterEditor$ConsolidatorTask.call(AtomicCounterEditor.java:410)
> at
> org.apache.jackrabbit.oak.plugins.atomic.AtomicCounterEditor$ConsolidatorTask.call(AtomicCounterEditor.java:335)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-6149) AtomicCounter fails with LuceneIndexEditorProvider
[
https://issues.apache.org/jira/browse/OAK-6149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15994674#comment-15994674
]
Davide Giannella commented on OAK-6149:
---
+1 for backport
> AtomicCounter fails with LuceneIndexEditorProvider
> --
>
> Key: OAK-6149
> URL: https://issues.apache.org/jira/browse/OAK-6149
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.6.0
> Environment: Oak 1.6.1 with DocumentNodeStore on MongoDB 3.2.x
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
> Labels: candidate_oak_1_6
> Fix For: 1.7.0, 1.8
>
> Attachments: OAK-6149.patch
>
>
> The AtomicCounter fails to consolidate the value when running on
> DocumentNodeStore with lucene indexes.
> The task scheduled by the {{AtomicCounterEditor}} fails with:
> {noformat}
> 02.05.2017 13:42:14.923 *WARN* [atomic-counter-3]
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorProvider No
> CommitContext found for commit
> java.lang.Exception: null
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorProvider.getIndexEditor(LuceneIndexEditorProvider.java:133)
> at
> org.apache.jackrabbit.oak.plugins.index.CompositeIndexEditorProvider.getIndexEditor(CompositeIndexEditorProvider.java:74)
> at
> org.apache.jackrabbit.oak.spi.whiteboard.WhiteboardIndexEditorProvider.getIndexEditor(WhiteboardIndexEditorProvider.java:52)
> at
> org.apache.jackrabbit.oak.plugins.index.IndexUpdate.collectIndexEditors(IndexUpdate.java:240)
> at
> org.apache.jackrabbit.oak.plugins.index.IndexUpdate.enter(IndexUpdate.java:160)
> at
> org.apache.jackrabbit.oak.spi.commit.VisibleEditor.enter(VisibleEditor.java:57)
> at
> org.apache.jackrabbit.oak.spi.commit.CompositeEditor.enter(CompositeEditor.java:66)
> at
> org.apache.jackrabbit.oak.spi.commit.EditorDiff.process(EditorDiff.java:49)
> at
> org.apache.jackrabbit.oak.spi.commit.EditorHook.processCommit(EditorHook.java:54)
> at
> org.apache.jackrabbit.oak.spi.commit.CompositeHook.processCommit(CompositeHook.java:61)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch$InMemory.merge(DocumentNodeStoreBranch.java:511)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch.merge0(DocumentNodeStoreBranch.java:185)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch.merge(DocumentNodeStoreBranch.java:119)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentRootBuilder.merge(DocumentRootBuilder.java:167)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.merge(DocumentNodeStore.java:1694)
> at
> org.apache.jackrabbit.oak.plugins.atomic.AtomicCounterEditor$ConsolidatorTask.call(AtomicCounterEditor.java:410)
> at
> org.apache.jackrabbit.oak.plugins.atomic.AtomicCounterEditor$ConsolidatorTask.call(AtomicCounterEditor.java:335)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-5947) Allowing non-admin user to set repository permissions fails
[
https://issues.apache.org/jira/browse/OAK-5947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15994663#comment-15994663
]
Alex Parvulescu commented on OAK-5947:
--
looks good to me!
the only (cosmetic) suggestion I have is to store the {{RepositoryPermission}}
directly in the {{RepoPolicyTreePermission}} instead of doing
{{compiledPermission.getRepositoryPermission()}} all the time.
> Allowing non-admin user to set repository permissions fails
> ---
>
> Key: OAK-5947
> URL: https://issues.apache.org/jira/browse/OAK-5947
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.0, 1.2, 1.4.0, 1.6.0
>Reporter: Julian Sedding
>Assignee: angela
> Fix For: 1.8
>
> Attachments: OAK-5947.patch, OAK-5947-tests.patch,
> SetRepoPolicyTest.patch
>
>
> Given a user principal {{testUser}} is granted {{jcr:readAccessControl}} and
> {{jcr:modifyAccessControl}} on the repository ({{rep:repoPolicy}}), I would
> expect that this user can e.g. allow {{everyone}} the
> {{jcr:namespaceManagement}} permission on the repository.
> Currently this fails with the following exception:
> {noformat}
> javax.jcr.PathNotFoundException: No tree at null
> at
> org.apache.jackrabbit.oak.spi.security.authorization.accesscontrol.AbstractAccessControlManager.getTree(AbstractAccessControlManager.java:163)
> at
> org.apache.jackrabbit.oak.security.authorization.accesscontrol.AccessControlManagerImpl.getApplicablePolicies(AccessControlManagerImpl.java:184)
> at
> org.apache.jackrabbit.oak.jcr.delegate.AccessControlManagerDelegator$7.perform(AccessControlManagerDelegator.java:121)
> at
> org.apache.jackrabbit.oak.jcr.delegate.AccessControlManagerDelegator$7.perform(AccessControlManagerDelegator.java:117)
> at
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.perform(SessionDelegate.java:208)
> at
> org.apache.jackrabbit.oak.jcr.delegate.AccessControlManagerDelegator.getApplicablePolicies(AccessControlManagerDelegator.java:117)
> at
> org.apache.jackrabbit.oak.jcr.delegate.JackrabbitAccessControlManagerDelegator.getApplicablePolicies(JackrabbitAccessControlManagerDelegator.java:147)
> at
> org.apache.jackrabbit.commons.jackrabbit.authorization.AccessControlUtils.getAccessControlList(AccessControlUtils.java:128)
> at
> org.apache.jackrabbit.oak.jcr.SetRepoPolicyPermissionsTest.setRepositoryPermissions(SetRepoPolicyPermissionsTest.java:85)
>
> {noformat}
> or after granting {{jcr:read}} on {{/}}:
> {noformat}
> javax.jcr.AccessDeniedException
> at org.apache.jackrabbit.oak.util.NodeUtil.addChild(NodeUtil.java:113)
> at
> org.apache.jackrabbit.oak.security.authorization.accesscontrol.AccessControlManagerImpl.setNodeBasedAcl(AccessControlManagerImpl.java:289)
> at
> org.apache.jackrabbit.oak.security.authorization.accesscontrol.AccessControlManagerImpl.setPolicy(AccessControlManagerImpl.java:220)
> at
> org.apache.jackrabbit.oak.jcr.delegate.AccessControlManagerDelegator$8.performVoid(AccessControlManagerDelegator.java:132)
> at
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.performVoid(SessionDelegate.java:274)
> at
> org.apache.jackrabbit.oak.jcr.delegate.AccessControlManagerDelegator.setPolicy(AccessControlManagerDelegator.java:129)
> at
> org.apache.jackrabbit.oak.jcr.delegate.JackrabbitAccessControlManagerDelegator.setPolicy(JackrabbitAccessControlManagerDelegator.java:152)
> at
> org.apache.jackrabbit.oak.jcr.SetRepoPolicyPermissionsTest.setRepositoryPermissions(SetRepoPolicyPermissionsTest.java:90)
>
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-6149) AtomicCounter fails with LuceneIndexEditorProvider
[
https://issues.apache.org/jira/browse/OAK-6149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15994662#comment-15994662
]
Chetan Mehrotra commented on OAK-6149:
--
+1 to backport
> AtomicCounter fails with LuceneIndexEditorProvider
> --
>
> Key: OAK-6149
> URL: https://issues.apache.org/jira/browse/OAK-6149
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.6.0
> Environment: Oak 1.6.1 with DocumentNodeStore on MongoDB 3.2.x
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
> Labels: candidate_oak_1_6
> Fix For: 1.7.0, 1.8
>
> Attachments: OAK-6149.patch
>
>
> The AtomicCounter fails to consolidate the value when running on
> DocumentNodeStore with lucene indexes.
> The task scheduled by the {{AtomicCounterEditor}} fails with:
> {noformat}
> 02.05.2017 13:42:14.923 *WARN* [atomic-counter-3]
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorProvider No
> CommitContext found for commit
> java.lang.Exception: null
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorProvider.getIndexEditor(LuceneIndexEditorProvider.java:133)
> at
> org.apache.jackrabbit.oak.plugins.index.CompositeIndexEditorProvider.getIndexEditor(CompositeIndexEditorProvider.java:74)
> at
> org.apache.jackrabbit.oak.spi.whiteboard.WhiteboardIndexEditorProvider.getIndexEditor(WhiteboardIndexEditorProvider.java:52)
> at
> org.apache.jackrabbit.oak.plugins.index.IndexUpdate.collectIndexEditors(IndexUpdate.java:240)
> at
> org.apache.jackrabbit.oak.plugins.index.IndexUpdate.enter(IndexUpdate.java:160)
> at
> org.apache.jackrabbit.oak.spi.commit.VisibleEditor.enter(VisibleEditor.java:57)
> at
> org.apache.jackrabbit.oak.spi.commit.CompositeEditor.enter(CompositeEditor.java:66)
> at
> org.apache.jackrabbit.oak.spi.commit.EditorDiff.process(EditorDiff.java:49)
> at
> org.apache.jackrabbit.oak.spi.commit.EditorHook.processCommit(EditorHook.java:54)
> at
> org.apache.jackrabbit.oak.spi.commit.CompositeHook.processCommit(CompositeHook.java:61)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch$InMemory.merge(DocumentNodeStoreBranch.java:511)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch.merge0(DocumentNodeStoreBranch.java:185)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch.merge(DocumentNodeStoreBranch.java:119)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentRootBuilder.merge(DocumentRootBuilder.java:167)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.merge(DocumentNodeStore.java:1694)
> at
> org.apache.jackrabbit.oak.plugins.atomic.AtomicCounterEditor$ConsolidatorTask.call(AtomicCounterEditor.java:410)
> at
> org.apache.jackrabbit.oak.plugins.atomic.AtomicCounterEditor$ConsolidatorTask.call(AtomicCounterEditor.java:335)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (OAK-6155) AccessControlManagerImpl: removing entries through principal-set-acl fails
[
https://issues.apache.org/jira/browse/OAK-6155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela reassigned OAK-6155:
---
Assignee: angela
> AccessControlManagerImpl: removing entries through principal-set-acl fails
> --
>
> Key: OAK-6155
> URL: https://issues.apache.org/jira/browse/OAK-6155
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Reporter: angela
>Assignee: angela
>Priority: Minor
> Fix For: 1.7.0, 1.8
>
>
> writing back a policy obtained through
> {{AccessControlManager.getPolicies(Principal)}} will fail with
> {{AccessControlException}} if removal of existing entries is involved. Reason
> for the failure is that the entries in that policy have an additional
> node-path restr set in order to be able to track their origin and thus will
> not match the real entry bound to the resource-based policy.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (OAK-6155) AccessControlManagerImpl: removing entries through principal-set-acl fails
angela created OAK-6155:
---
Summary: AccessControlManagerImpl: removing entries through
principal-set-acl fails
Key: OAK-6155
URL: https://issues.apache.org/jira/browse/OAK-6155
Project: Jackrabbit Oak
Issue Type: Bug
Components: core
Reporter: angela
Priority: Minor
Fix For: 1.7.0, 1.8
writing back a policy obtained through
{{AccessControlManager.getPolicies(Principal)}} will fail with
{{AccessControlException}} if removal of existing entries is involved. Reason
for the failure is that the entries in that policy have an additional node-path
restr set in order to be able to track their origin and thus will not match the
real entry bound to the resource-based policy.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-6136) Extract the multiplexing implementation code into a separate bundle
[ https://issues.apache.org/jira/browse/OAK-6136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15994618#comment-15994618 ] Robert Munteanu commented on OAK-6136: -- I am not sure that federation is the proper term for what we currently have ( and also for what we want to have ) in Oak. Federation to me see to be about different services becoming interoperable More importantly I think it's about existing services that work in a standalone fashion but can also work together - in a federated mode. See - https://dev.mysql.com/doc/refman/5.7/en/federated-storage-engine.html - https://en.wikipedia.org/wiki/Federated_database_system In our scenario the mounts - those which we assemble - are not really usable by themselves as they only contain a part of the repository. I think multiplexing is a better metaphor. It originally was about combining multiple signals into a single one. I have no experience with telecommunications so I won't comment on that but for me the concept of combining multiple parts into a larger one is closer to what we offer with our implementation. So yes, naming is tricky, multiplexing is maybe not the best option, but I think federation gets us further from what we actually do. > Extract the multiplexing implementation code into a separate bundle > --- > > Key: OAK-6136 > URL: https://issues.apache.org/jira/browse/OAK-6136 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: federated >Reporter: Robert Munteanu >Assignee: Julian Sedding > Fix For: 1.7.0, 1.8 > > Attachments: > 0001-OAK-6136-Extract-the-multiplexing-implementation-cod.patch, > OAK-6136.patch > > > Since we already kicked off the m12n effort for 1.8 it would be good to > separate the multiplexing implementation from oak-core into its own bundle as > well. > I will look into providing a patch for the change. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (OAK-6149) AtomicCounter fails with LuceneIndexEditorProvider
[
https://issues.apache.org/jira/browse/OAK-6149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger updated OAK-6149:
--
Labels: candidate_oak_1_6 (was: )
I would like to merge this fix into the 1.6 branch. The fix is simple and I
consider the risk as low. Without this fix, the atomic counter cannot be used
in combination with Lucene based indexes that are configured with either 'nrt'
or 'sync' mode.
[~chetanm], WDYT?
> AtomicCounter fails with LuceneIndexEditorProvider
> --
>
> Key: OAK-6149
> URL: https://issues.apache.org/jira/browse/OAK-6149
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.6.0
> Environment: Oak 1.6.1 with DocumentNodeStore on MongoDB 3.2.x
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
> Labels: candidate_oak_1_6
> Fix For: 1.7.0, 1.8
>
> Attachments: OAK-6149.patch
>
>
> The AtomicCounter fails to consolidate the value when running on
> DocumentNodeStore with lucene indexes.
> The task scheduled by the {{AtomicCounterEditor}} fails with:
> {noformat}
> 02.05.2017 13:42:14.923 *WARN* [atomic-counter-3]
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorProvider No
> CommitContext found for commit
> java.lang.Exception: null
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorProvider.getIndexEditor(LuceneIndexEditorProvider.java:133)
> at
> org.apache.jackrabbit.oak.plugins.index.CompositeIndexEditorProvider.getIndexEditor(CompositeIndexEditorProvider.java:74)
> at
> org.apache.jackrabbit.oak.spi.whiteboard.WhiteboardIndexEditorProvider.getIndexEditor(WhiteboardIndexEditorProvider.java:52)
> at
> org.apache.jackrabbit.oak.plugins.index.IndexUpdate.collectIndexEditors(IndexUpdate.java:240)
> at
> org.apache.jackrabbit.oak.plugins.index.IndexUpdate.enter(IndexUpdate.java:160)
> at
> org.apache.jackrabbit.oak.spi.commit.VisibleEditor.enter(VisibleEditor.java:57)
> at
> org.apache.jackrabbit.oak.spi.commit.CompositeEditor.enter(CompositeEditor.java:66)
> at
> org.apache.jackrabbit.oak.spi.commit.EditorDiff.process(EditorDiff.java:49)
> at
> org.apache.jackrabbit.oak.spi.commit.EditorHook.processCommit(EditorHook.java:54)
> at
> org.apache.jackrabbit.oak.spi.commit.CompositeHook.processCommit(CompositeHook.java:61)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch$InMemory.merge(DocumentNodeStoreBranch.java:511)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch.merge0(DocumentNodeStoreBranch.java:185)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch.merge(DocumentNodeStoreBranch.java:119)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentRootBuilder.merge(DocumentRootBuilder.java:167)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.merge(DocumentNodeStore.java:1694)
> at
> org.apache.jackrabbit.oak.plugins.atomic.AtomicCounterEditor$ConsolidatorTask.call(AtomicCounterEditor.java:410)
> at
> org.apache.jackrabbit.oak.plugins.atomic.AtomicCounterEditor$ConsolidatorTask.call(AtomicCounterEditor.java:335)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (OAK-5412) Use GCMonitor for revision gc task run in DocumentNodeStore
[
https://issues.apache.org/jira/browse/OAK-5412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger resolved OAK-5412.
---
Resolution: Fixed
Fix Version/s: 1.7.0
Applied remaining part of the patch to trunk: http://svn.apache.org/r1793630
> Use GCMonitor for revision gc task run in DocumentNodeStore
> ---
>
> Key: OAK-5412
> URL: https://issues.apache.org/jira/browse/OAK-5412
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, documentmk
>Reporter: Chetan Mehrotra
>Assignee: Marcel Reutegger
> Fix For: 1.7.0, 1.8
>
> Attachments: OAK-5412.patch
>
>
> DocumentNodeStore should use {{GCMonitor}} to inform interested parties about
> GC task progress (similar to how its used in SegmentNodeStore)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (OAK-6140) Create RDB-specific BlobReferenceIterator
[
https://issues.apache.org/jira/browse/OAK-6140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-6140:
Fix Version/s: 1.8
> Create RDB-specific BlobReferenceIterator
> -
>
> Key: OAK-6140
> URL: https://issues.apache.org/jira/browse/OAK-6140
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: rdbmk
>Reporter: Julian Reschke
>Assignee: Julian Reschke
> Fix For: 1.8
>
>
> Mirroring {{MongoBlobReferenceIterator}}, using the capabilities added in
> OAK-5855.
> (might lead to refactoring of {{MongoBlobReferenceIterator}})
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (OAK-6122) enforce oak-run size
[
https://issues.apache.org/jira/browse/OAK-6122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15993006#comment-15993006
]
Julian Reschke edited comment on OAK-6122 at 5/3/17 8:47 AM:
-
Proposed patch allowing to override the limit using {{max.jar.size}}.
EDIT: applied in [r1793628|http://svn.apache.org/r1793628]
was (Author: reschke):
Proposed patch allowing to override the limit using {{max.jar.size}}.
> enforce oak-run size
>
>
> Key: OAK-6122
> URL: https://issues.apache.org/jira/browse/OAK-6122
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: run
>Reporter: Davide Giannella
>Assignee: Davide Giannella
> Fix For: 1.7.0, 1.8
>
> Attachments: mvn.log, oak-run-size-configurable.diff
>
>
> In order to avoid again an uncontrolled growing of oak-run let's enforce some
> size control.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-6122) enforce oak-run size
[ https://issues.apache.org/jira/browse/OAK-6122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15994483#comment-15994483 ] Julian Reschke commented on OAK-6122: - trunk: [r1793628|http://svn.apache.org/r1793628] [r1792478|http://svn.apache.org/r1792478] [r1792466|http://svn.apache.org/r1792466] [r1792452|http://svn.apache.org/r1792452] > enforce oak-run size > > > Key: OAK-6122 > URL: https://issues.apache.org/jira/browse/OAK-6122 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: run >Reporter: Davide Giannella >Assignee: Davide Giannella > Fix For: 1.7.0, 1.8 > > Attachments: mvn.log, oak-run-size-configurable.diff > > > In order to avoid again an uncontrolled growing of oak-run let's enforce some > size control. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (OAK-6149) AtomicCounter fails with LuceneIndexEditorProvider
[
https://issues.apache.org/jira/browse/OAK-6149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger resolved OAK-6149.
---
Resolution: Fixed
Fix Version/s: 1.7.0
Fixed in trunk: http://svn.apache.org/r1793627
> AtomicCounter fails with LuceneIndexEditorProvider
> --
>
> Key: OAK-6149
> URL: https://issues.apache.org/jira/browse/OAK-6149
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.6.0
> Environment: Oak 1.6.1 with DocumentNodeStore on MongoDB 3.2.x
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
> Fix For: 1.7.0, 1.8
>
> Attachments: OAK-6149.patch
>
>
> The AtomicCounter fails to consolidate the value when running on
> DocumentNodeStore with lucene indexes.
> The task scheduled by the {{AtomicCounterEditor}} fails with:
> {noformat}
> 02.05.2017 13:42:14.923 *WARN* [atomic-counter-3]
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorProvider No
> CommitContext found for commit
> java.lang.Exception: null
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorProvider.getIndexEditor(LuceneIndexEditorProvider.java:133)
> at
> org.apache.jackrabbit.oak.plugins.index.CompositeIndexEditorProvider.getIndexEditor(CompositeIndexEditorProvider.java:74)
> at
> org.apache.jackrabbit.oak.spi.whiteboard.WhiteboardIndexEditorProvider.getIndexEditor(WhiteboardIndexEditorProvider.java:52)
> at
> org.apache.jackrabbit.oak.plugins.index.IndexUpdate.collectIndexEditors(IndexUpdate.java:240)
> at
> org.apache.jackrabbit.oak.plugins.index.IndexUpdate.enter(IndexUpdate.java:160)
> at
> org.apache.jackrabbit.oak.spi.commit.VisibleEditor.enter(VisibleEditor.java:57)
> at
> org.apache.jackrabbit.oak.spi.commit.CompositeEditor.enter(CompositeEditor.java:66)
> at
> org.apache.jackrabbit.oak.spi.commit.EditorDiff.process(EditorDiff.java:49)
> at
> org.apache.jackrabbit.oak.spi.commit.EditorHook.processCommit(EditorHook.java:54)
> at
> org.apache.jackrabbit.oak.spi.commit.CompositeHook.processCommit(CompositeHook.java:61)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch$InMemory.merge(DocumentNodeStoreBranch.java:511)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch.merge0(DocumentNodeStoreBranch.java:185)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch.merge(DocumentNodeStoreBranch.java:119)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentRootBuilder.merge(DocumentRootBuilder.java:167)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.merge(DocumentNodeStore.java:1694)
> at
> org.apache.jackrabbit.oak.plugins.atomic.AtomicCounterEditor$ConsolidatorTask.call(AtomicCounterEditor.java:410)
> at
> org.apache.jackrabbit.oak.plugins.atomic.AtomicCounterEditor$ConsolidatorTask.call(AtomicCounterEditor.java:335)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (OAK-6154) Use Closer in DocumentNodeStoreService
[
https://issues.apache.org/jira/browse/OAK-6154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger resolved OAK-6154.
---
Resolution: Fixed
Fix Version/s: 1.7.0
Done in trunk: http://svn.apache.org/r1793625
> Use Closer in DocumentNodeStoreService
> --
>
> Key: OAK-6154
> URL: https://issues.apache.org/jira/browse/OAK-6154
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: documentmk
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
>Priority: Minor
> Fix For: 1.7.0, 1.8
>
>
> {{DocumentNodeStoreService}} currently uses a list of {{Registration}} to
> keep track of resources it needs to release when deactivated. Replacing the
> list with a {{Closer}} allows the service to track other resources than just
> {{Registration}}.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-5412) Use GCMonitor for revision gc task run in DocumentNodeStore
[
https://issues.apache.org/jira/browse/OAK-5412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15994474#comment-15994474
]
Marcel Reutegger commented on OAK-5412:
---
Moved the Closer refactoring to OAK-6154.
> Use GCMonitor for revision gc task run in DocumentNodeStore
> ---
>
> Key: OAK-5412
> URL: https://issues.apache.org/jira/browse/OAK-5412
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, documentmk
>Reporter: Chetan Mehrotra
>Assignee: Marcel Reutegger
> Fix For: 1.8
>
> Attachments: OAK-5412.patch
>
>
> DocumentNodeStore should use {{GCMonitor}} to inform interested parties about
> GC task progress (similar to how its used in SegmentNodeStore)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (OAK-5506) Segment store apparently doesn't round trip node names with unpaired surrogates
[
https://issues.apache.org/jira/browse/OAK-5506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig updated OAK-5506:
---
Issue Type: Wish (was: Bug)
> Segment store apparently doesn't round trip node names with unpaired
> surrogates
> ---
>
> Key: OAK-5506
> URL: https://issues.apache.org/jira/browse/OAK-5506
> Project: Jackrabbit Oak
> Issue Type: Wish
> Components: segment-tar
>Affects Versions: 1.5.18
>Reporter: Julian Reschke
>Assignee: Francesco Mari
>Priority: Minor
> Fix For: 1.8
>
> Attachments: OAK-5506-01.patch, OAK-5506-02.patch,
> OAK-5506-name-conversion.diff, ValidNamesTest.java
>
>
> Apparently, the following node name is accepted:
>{{"foo\ud800"}}
> but a subsequent {{getPath()}} call fails:
> {noformat}
> javax.jcr.InvalidItemStateException: This item [/test_node/foo?] does not
> exist anymore
> at
> org.apache.jackrabbit.oak.jcr.delegate.ItemDelegate.checkAlive(ItemDelegate.java:86)
> at
> org.apache.jackrabbit.oak.jcr.session.operation.ItemOperation.checkPreconditions(ItemOperation.java:34)
> at
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.prePerform(SessionDelegate.java:615)
> at
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.perform(SessionDelegate.java:205)
> at
> org.apache.jackrabbit.oak.jcr.session.ItemImpl.perform(ItemImpl.java:112)
> at
> org.apache.jackrabbit.oak.jcr.session.ItemImpl.getPath(ItemImpl.java:140)
> at
> org.apache.jackrabbit.oak.jcr.session.NodeImpl.getPath(NodeImpl.java:106)
> at
> org.apache.jackrabbit.oak.jcr.ValidNamesTest.nameTest(ValidNamesTest.java:271)
> at
> org.apache.jackrabbit.oak.jcr.ValidNamesTest.testUnpairedSurrogate(ValidNamesTest.java:259)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source){noformat}
> (test case follows)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-5412) Use GCMonitor for revision gc task run in DocumentNodeStore
[
https://issues.apache.org/jira/browse/OAK-5412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15994469#comment-15994469
]
Marcel Reutegger commented on OAK-5412:
---
{{LoggingGCMonitor}} is segment-tar specific and cannot be used by
{{VersionGarbageCollector}}. Similar functionality in the patch is implemented
in {{VersionGarbageCollector.VersionGCMonitor}}, which is combined with the
{{GCMonitor}} provided in the {{DocumentMK.Builder}} using a
{{DelegatingGCMonitor}} in the {{GCJob}} constructor.
> Use GCMonitor for revision gc task run in DocumentNodeStore
> ---
>
> Key: OAK-5412
> URL: https://issues.apache.org/jira/browse/OAK-5412
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, documentmk
>Reporter: Chetan Mehrotra
>Assignee: Marcel Reutegger
> Fix For: 1.8
>
> Attachments: OAK-5412.patch
>
>
> DocumentNodeStore should use {{GCMonitor}} to inform interested parties about
> GC task progress (similar to how its used in SegmentNodeStore)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Issue Comment Deleted] (OAK-5412) Use GCMonitor for revision gc task run in DocumentNodeStore
[
https://issues.apache.org/jira/browse/OAK-5412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger updated OAK-5412:
--
Comment: was deleted
(was: {{LoggingGCMonitor}} is segment-tar specific and cannot be used by
{{VersionGarbageCollector}}. Similar functionality in the patch is implemented
in {{VersionGarbageCollector.VersionGCMonitor}}, which is combined with the
{{GCMonitor}} provided in the {{DocumentMK.Builder}} using a
{{DelegatingGCMonitor}} in the {{GCJob}} constructor.)
> Use GCMonitor for revision gc task run in DocumentNodeStore
> ---
>
> Key: OAK-5412
> URL: https://issues.apache.org/jira/browse/OAK-5412
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, documentmk
>Reporter: Chetan Mehrotra
>Assignee: Marcel Reutegger
> Fix For: 1.8
>
> Attachments: OAK-5412.patch
>
>
> DocumentNodeStore should use {{GCMonitor}} to inform interested parties about
> GC task progress (similar to how its used in SegmentNodeStore)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-5412) Use GCMonitor for revision gc task run in DocumentNodeStore
[
https://issues.apache.org/jira/browse/OAK-5412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15994470#comment-15994470
]
Marcel Reutegger commented on OAK-5412:
---
{{LoggingGCMonitor}} is segment-tar specific and cannot be used by
{{VersionGarbageCollector}}. Similar functionality in the patch is implemented
in {{VersionGarbageCollector.VersionGCMonitor}}, which is combined with the
{{GCMonitor}} provided in the {{DocumentMK.Builder}} using a
{{DelegatingGCMonitor}} in the {{GCJob}} constructor.
> Use GCMonitor for revision gc task run in DocumentNodeStore
> ---
>
> Key: OAK-5412
> URL: https://issues.apache.org/jira/browse/OAK-5412
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, documentmk
>Reporter: Chetan Mehrotra
>Assignee: Marcel Reutegger
> Fix For: 1.8
>
> Attachments: OAK-5412.patch
>
>
> DocumentNodeStore should use {{GCMonitor}} to inform interested parties about
> GC task progress (similar to how its used in SegmentNodeStore)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-4732) (Slightly) prioritise reads over writes
[
https://issues.apache.org/jira/browse/OAK-4732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15994468#comment-15994468
]
Michael Dürig commented on OAK-4732:
[~dulceanu], tentatively assigned to you as it might make sense to take this up
again in the context of your work towards better commit scheduling strategies.
> (Slightly) prioritise reads over writes
>
>
> Key: OAK-4732
> URL: https://issues.apache.org/jira/browse/OAK-4732
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Reporter: Michael Dürig
>Assignee: Andrei Dulceanu
>Priority: Minor
> Labels: Performance, scalability
> Fix For: 1.8
>
>
> When fetching the current root from the {{SegmentNodeStore}} an older
> revision will be returned when a commit is being processed concurrently. I
> think it would make sense to wait for a short time in this case increasing
> the chance of returning an up to date state. The idea is that this would
> lower the rebasing work that need to be done later on should the returned
> root be used for further modifications.
> An interesting value for the wait time is to use the median (or more general
> a percentile) of the commit time of the last say 1000 commits. This would
> mean that (for the median) we have a 50% chance of getting up to date date.
> For a 90% percentile we would have longer wait times but then a 90% chance of
> getting up to date date.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (OAK-4732) (Slightly) prioritise reads over writes
[
https://issues.apache.org/jira/browse/OAK-4732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig reassigned OAK-4732:
--
Assignee: Andrei Dulceanu (was: Michael Dürig)
> (Slightly) prioritise reads over writes
>
>
> Key: OAK-4732
> URL: https://issues.apache.org/jira/browse/OAK-4732
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Reporter: Michael Dürig
>Assignee: Andrei Dulceanu
>Priority: Minor
> Labels: Performance, scalability
> Fix For: 1.8
>
>
> When fetching the current root from the {{SegmentNodeStore}} an older
> revision will be returned when a commit is being processed concurrently. I
> think it would make sense to wait for a short time in this case increasing
> the chance of returning an up to date state. The idea is that this would
> lower the rebasing work that need to be done later on should the returned
> root be used for further modifications.
> An interesting value for the wait time is to use the median (or more general
> a percentile) of the commit time of the last say 1000 commits. This would
> mean that (for the median) we have a 50% chance of getting up to date date.
> For a 90% percentile we would have longer wait times but then a 90% chance of
> getting up to date date.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (OAK-6030) Add tests for TarFiles
[
https://issues.apache.org/jira/browse/OAK-6030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig updated OAK-6030:
---
Fix Version/s: 1.7.0
> Add tests for TarFiles
> --
>
> Key: OAK-6030
> URL: https://issues.apache.org/jira/browse/OAK-6030
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Reporter: Francesco Mari
>Assignee: Francesco Mari
> Fix For: 1.7.0, 1.8
>
>
> Some tests should be added for the newly added {{TarFiles}}.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (OAK-1553) More sophisticated conflict resolution when concurrently adding nodes
[
https://issues.apache.org/jira/browse/OAK-1553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-1553:
Component/s: segment-tar
documentmk
> More sophisticated conflict resolution when concurrently adding nodes
> -
>
> Key: OAK-1553
> URL: https://issues.apache.org/jira/browse/OAK-1553
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, documentmk, segment-tar
>Reporter: Michael Dürig
>Assignee: Michael Dürig
> Labels: concurrency, scalability, technical_debt
> Attachments: OAK-1553.patch
>
>
> {{MicroKernel.rebase}} currently specifies: "addExistingNode: A node has been
> added that is different from a node of them same name that has been added to
> the trunk."
> This is somewhat troublesome in the case where the same node with different
> but non conflicting child items is added concurrently:
> {code}
> f.add("fo").add("u1"); commit();
> f.add("fo").add("u2"); commit();
> {code}
> currently fails with a conflict because {{fo}} is not the same node for the
> both cases. See discussion http://markmail.org/message/flst4eiqvbp4gi3z
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (OAK-1553) More sophisticated conflict resolution when concurrently adding nodes
[
https://issues.apache.org/jira/browse/OAK-1553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=13938283#comment-13938283
]
Julian Reschke edited comment on OAK-1553 at 5/3/17 8:20 AM:
-
Note: in addition to the {{MicroKernel}} implementations this will also need
fixing in {{AbstractRebaseDiff}}, which is an in-memory implementation of the
same contract.
was (Author: mduerig):
Note: in addition to the {{MicorKernel}} implementations this will also need
fixing in {{AbstractRebaseDiff}}, which is an in-memory implementation of the
same contract.
> More sophisticated conflict resolution when concurrently adding nodes
> -
>
> Key: OAK-1553
> URL: https://issues.apache.org/jira/browse/OAK-1553
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Reporter: Michael Dürig
>Assignee: Michael Dürig
> Labels: concurrency, scalability, technical_debt
> Attachments: OAK-1553.patch
>
>
> {{MicroKernel.rebase}} currently specifies: "addExistingNode: A node has been
> added that is different from a node of them same name that has been added to
> the trunk."
> This is somewhat troublesome in the case where the same node with different
> but non conflicting child items is added concurrently:
> {code}
> f.add("fo").add("u1"); commit();
> f.add("fo").add("u2"); commit();
> {code}
> currently fails with a conflict because {{fo}} is not the same node for the
> both cases. See discussion http://markmail.org/message/flst4eiqvbp4gi3z
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (OAK-1553) More sophisticated conflict resolution when concurrently adding nodes
[
https://issues.apache.org/jira/browse/OAK-1553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-1553:
Component/s: (was: segment-tar)
(was: mongomk)
> More sophisticated conflict resolution when concurrently adding nodes
> -
>
> Key: OAK-1553
> URL: https://issues.apache.org/jira/browse/OAK-1553
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Reporter: Michael Dürig
>Assignee: Michael Dürig
> Labels: concurrency, scalability, technical_debt
> Attachments: OAK-1553.patch
>
>
> {{MicroKernel.rebase}} currently specifies: "addExistingNode: A node has been
> added that is different from a node of them same name that has been added to
> the trunk."
> This is somewhat troublesome in the case where the same node with different
> but non conflicting child items is added concurrently:
> {code}
> f.add("fo").add("u1"); commit();
> f.add("fo").add("u2"); commit();
> {code}
> currently fails with a conflict because {{fo}} is not the same node for the
> both cases. See discussion http://markmail.org/message/flst4eiqvbp4gi3z
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (OAK-5192) Reduce Lucene related growth of repository size
[ https://issues.apache.org/jira/browse/OAK-5192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dürig updated OAK-5192: --- Fix Version/s: 1.7.3 > Reduce Lucene related growth of repository size > --- > > Key: OAK-5192 > URL: https://issues.apache.org/jira/browse/OAK-5192 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: lucene, segment-tar >Reporter: Michael Dürig > Labels: perfomance, scalability > Fix For: 1.8, 1.7.3 > > Attachments: added-bytes-zoom.png > > > I observed Lucene indexing contributing to up to 99% of repository growth. > While the size of the index itself is well inside reasonable bounds, the > overall turnover of data being written and removed again can be as much as > 99%. > In the case of the TarMK this negatively impacts overall system performance > due to fast growing number of tar files / segments, bad locality of > reference, cache misses/thrashing when looking up segments and vastly > prolonged garbage collection cycles. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (OAK-2808) Active deletion of 'deleted' Lucene index files from DataStore without relying on full scale Blob GC
[ https://issues.apache.org/jira/browse/OAK-2808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15994452#comment-15994452 ] Chetan Mehrotra commented on OAK-2808: -- bq. What about if we do regular index updates as we do now every few seconds, but only locally (on the local file system), and only persist the index (to the repository) every x minutes. That would be tricky as the async indexer would have released the checkpoint and move forward assuming index is upto date. So in case of any crash it would not be possible to determine what needs to be indexed. > Active deletion of 'deleted' Lucene index files from DataStore without > relying on full scale Blob GC > > > Key: OAK-2808 > URL: https://issues.apache.org/jira/browse/OAK-2808 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: lucene >Reporter: Chetan Mehrotra >Assignee: Thomas Mueller > Labels: datastore, performance > Fix For: 1.8 > > Attachments: copyonread-stats.png, OAK-2808-1.patch > > > With storing of Lucene index files within DataStore our usage pattern > of DataStore has changed between JR2 and Oak. > With JR2 the writes were mostly application based i.e. if application > stores a pdf/image file then that would be stored in DataStore. JR2 by > default would not write stuff to DataStore. Further in deployment > where large number of binary content is present then systems tend to > share the DataStore to avoid duplication of storage. In such cases > running Blob GC is a non trivial task as it involves a manual step and > coordination across multiple deployments. Due to this systems tend to > delay frequency of GC > Now with Oak apart from application the Oak system itself *actively* > uses the DataStore to store the index files for Lucene and there the > churn might be much higher i.e. frequency of creation and deletion of > index file is lot higher. This would accelerate the rate of garbage > generation and thus put lot more pressure on the DataStore storage > requirements. > Discussion thread http://markmail.org/thread/iybd3eq2bh372zrl -- This message was sent by Atlassian JIRA (v6.3.15#6346)
