[jira] [Commented] (OAK-4114) Cached lucene index gets corrupted in case of unclean shutdown and journal rollback in SegmentNodeStore
[
https://issues.apache.org/jira/browse/OAK-4114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15614020#comment-15614020
]
Abhishek Sharma commented on OAK-4114:
--
Is there any update on this issue.
The lucene index for AEM 6.1 Oak repository is corrupted on restart at times
which takes gignificant time to build.
> Cached lucene index gets corrupted in case of unclean shutdown and journal
> rollback in SegmentNodeStore
> ---
>
> Key: OAK-4114
> URL: https://issues.apache.org/jira/browse/OAK-4114
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Labels: resilience
> Fix For: 1.6
>
>
> Currently Oak Lucene support would copy index files to local file system as
> part of CopyOnRead feature. In one of the setup it has been observed that
> index logic was failing with following error
> {noformat}
> 04.02.2016 17:47:52.391 *WARN* [oak-lucene-3]
> org.apache.jackrabbit.oak.plugins.index.lucene.IndexCopier
> [/oak:index/lucene] Found local copy for _2ala.cfs in
> MMapDirectory@/mnt/crx/author/crx-quickstart/repository/index/e5a943cdec3000bd8ce54924fd2070ab5d1d35b9ecf530963a3583d43bf28293/1
>
> lockFactory=NativeFSLockFactory@/mnt/crx/author/crx-quickstart/repository/index/e5a943cdec3000bd8ce54924fd2070ab5d1d35b9ecf530963a3583d43bf28293/1
> but size of local 9320 differs from remote 3714150. Content would be read
> from remote file only
> 04.02.2016 17:47:52.399 *WARN* [oak-lucene-3]
> org.apache.jackrabbit.oak.plugins.index.lucene.IndexCopier
> [/oak:index/lucene] Found local copy for segments_28je in
> MMapDirectory@/mnt/crx/author/crx-quickstart/repository/index/e5a943cdec3000bd8ce54924fd2070ab5d1d35b9ecf530963a3583d43bf28293/1
>
> lockFactory=NativeFSLockFactory@/mnt/crx/author/crx-quickstart/repository/index/e5a943cdec3000bd8ce54924fd2070ab5d1d35b9ecf530963a3583d43bf28293/1
> but size of local 1214 differs from remote 1175. Content would be read from
> remote file only
> 04.02.2016 17:47:52.491 *ERROR* [oak-lucene-3]
> org.apache.jackrabbit.oak.plugins.index.lucene.IndexTracker Failed to open
> Lucene index at /oak:index/lucene
> org.apache.lucene.index.CorruptIndexException: codec header mismatch: actual
> header=1953790076 vs expected header=1071082519 (resource:
> SlicedIndexInput(SlicedIndexInput(_2ala.fnm in _2ala.cfs) in _2ala.cfs
> slice=8810:9320))
> at org.apache.lucene.codecs.CodecUtil.checkHeader(CodecUtil.java:128)
> at
> org.apache.lucene.codecs.lucene46.Lucene46FieldInfosReader.read(Lucene46FieldInfosReader.java:56)
> at
> org.apache.lucene.index.SegmentReader.readFieldInfos(SegmentReader.java:215)
> {noformat}
> Here size of __2ala.cfs_ differed from remote copy and possible other index
> file may have same size but different content. Comparing the modified time of
> the files with those in Oak it can be seen that one of file system was older
> than one in Oak
> {noformat}
> _2alr.cfs={name=_2alr.cfs, size=1152402, sizeStr=1.2 MB, modified=Thu Feb 04
> 17:52:31 GMT 2016, osModified=Feb 4 17:52, osSize=1152402, mismatch=false}
> _2ala.cfe={name=_2ala.cfe, size=224, sizeStr=224 B, modified=Thu Feb 04
> 17:47:28 GMT 2016, osModified=Feb 4 17:17, osSize=224, mismatch=false}
> _2ala.si={name=_2ala.si, size=252, sizeStr=252 B, modified=Thu Feb 04
> 17:47:28 GMT 2016, osModified=Feb 4 17:17, osSize=252, mismatch=false}
> _2ala.cfs={name=_2ala.cfs, size=3714150, sizeStr=3.7 MB, modified=Thu Feb 04
> 17:47:28 GMT 2016, osModified=Feb 4 17:17, osSize=9320, mismatch=true}
> _14u3_29.del={name=_14u3_29.del, size=1244036, sizeStr=1.2 MB, modified=Thu
> Feb 04 16:37:35 GMT 2016, osModified=Feb 4 16:37, osSize=1244036,
> mismatch=false}
> _2akw.si={name=_2akw.si, size=252, sizeStr=252 B, modified=Thu Feb 04
> 16:37:07 GMT 2016, osModified=Feb 4 16:37, osSize=252, mismatch=false}
> _2akw.cfe={name=_2akw.cfe, size=224, sizeStr=224 B, modified=Thu Feb 04
> 16:37:07 GMT 2016, osModified=Feb 4 16:37, osSize=224, mismatch=false}
> _2akw.cfs={name=_2akw.cfs, size=4952761, sizeStr=5.0 MB, modified=Thu Feb 04
> 16:37:07 GMT 2016, osModified=Feb 4 16:37, osSize=4952761, mismatch=false}
> {noformat}
> And on same setup the system did saw a rollback in segment node store
> {noformat}
> -rw-rw-r--. 1 crx crx 25961984 Feb 4 16:47 data01357a.tar
> -rw-rw-r--. 1 crx crx 24385536 Feb 4 16:41 data01357a.tar.bak
> -rw-rw-r--. 1 crx crx359936 Feb 4 17:18 data01358a.tar
> -rw-rw-r--. 1 crx crx345088 Feb 4 17:17 data01358a.tar.bak
> -rw-rw-r--. 1 crx crx 70582272 Feb 4 18:35 data01359a.tar
> -rw-rw-r--. 1 crx crx 66359296 Feb 4 18:33 data01359a.tar.bak
> -rw-rw-r--. 1 crx crx
[jira] [Comment Edited] (OAK-4114) Cached lucene index gets corrupted in case of unclean shutdown and journal rollback in SegmentNodeStore
[
https://issues.apache.org/jira/browse/OAK-4114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15614020#comment-15614020
]
Abhishek Sharma edited comment on OAK-4114 at 10/28/16 2:14 AM:
Is there any update on this issue.
The lucene index for AEM 6.1 Oak repository is corrupted on restart at times
which takes significant time to build.
was (Author: aurorabhi):
Is there any update on this issue.
The lucene index for AEM 6.1 Oak repository is corrupted on restart at times
which takes gignificant time to build.
> Cached lucene index gets corrupted in case of unclean shutdown and journal
> rollback in SegmentNodeStore
> ---
>
> Key: OAK-4114
> URL: https://issues.apache.org/jira/browse/OAK-4114
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Labels: resilience
> Fix For: 1.6
>
>
> Currently Oak Lucene support would copy index files to local file system as
> part of CopyOnRead feature. In one of the setup it has been observed that
> index logic was failing with following error
> {noformat}
> 04.02.2016 17:47:52.391 *WARN* [oak-lucene-3]
> org.apache.jackrabbit.oak.plugins.index.lucene.IndexCopier
> [/oak:index/lucene] Found local copy for _2ala.cfs in
> MMapDirectory@/mnt/crx/author/crx-quickstart/repository/index/e5a943cdec3000bd8ce54924fd2070ab5d1d35b9ecf530963a3583d43bf28293/1
>
> lockFactory=NativeFSLockFactory@/mnt/crx/author/crx-quickstart/repository/index/e5a943cdec3000bd8ce54924fd2070ab5d1d35b9ecf530963a3583d43bf28293/1
> but size of local 9320 differs from remote 3714150. Content would be read
> from remote file only
> 04.02.2016 17:47:52.399 *WARN* [oak-lucene-3]
> org.apache.jackrabbit.oak.plugins.index.lucene.IndexCopier
> [/oak:index/lucene] Found local copy for segments_28je in
> MMapDirectory@/mnt/crx/author/crx-quickstart/repository/index/e5a943cdec3000bd8ce54924fd2070ab5d1d35b9ecf530963a3583d43bf28293/1
>
> lockFactory=NativeFSLockFactory@/mnt/crx/author/crx-quickstart/repository/index/e5a943cdec3000bd8ce54924fd2070ab5d1d35b9ecf530963a3583d43bf28293/1
> but size of local 1214 differs from remote 1175. Content would be read from
> remote file only
> 04.02.2016 17:47:52.491 *ERROR* [oak-lucene-3]
> org.apache.jackrabbit.oak.plugins.index.lucene.IndexTracker Failed to open
> Lucene index at /oak:index/lucene
> org.apache.lucene.index.CorruptIndexException: codec header mismatch: actual
> header=1953790076 vs expected header=1071082519 (resource:
> SlicedIndexInput(SlicedIndexInput(_2ala.fnm in _2ala.cfs) in _2ala.cfs
> slice=8810:9320))
> at org.apache.lucene.codecs.CodecUtil.checkHeader(CodecUtil.java:128)
> at
> org.apache.lucene.codecs.lucene46.Lucene46FieldInfosReader.read(Lucene46FieldInfosReader.java:56)
> at
> org.apache.lucene.index.SegmentReader.readFieldInfos(SegmentReader.java:215)
> {noformat}
> Here size of __2ala.cfs_ differed from remote copy and possible other index
> file may have same size but different content. Comparing the modified time of
> the files with those in Oak it can be seen that one of file system was older
> than one in Oak
> {noformat}
> _2alr.cfs={name=_2alr.cfs, size=1152402, sizeStr=1.2 MB, modified=Thu Feb 04
> 17:52:31 GMT 2016, osModified=Feb 4 17:52, osSize=1152402, mismatch=false}
> _2ala.cfe={name=_2ala.cfe, size=224, sizeStr=224 B, modified=Thu Feb 04
> 17:47:28 GMT 2016, osModified=Feb 4 17:17, osSize=224, mismatch=false}
> _2ala.si={name=_2ala.si, size=252, sizeStr=252 B, modified=Thu Feb 04
> 17:47:28 GMT 2016, osModified=Feb 4 17:17, osSize=252, mismatch=false}
> _2ala.cfs={name=_2ala.cfs, size=3714150, sizeStr=3.7 MB, modified=Thu Feb 04
> 17:47:28 GMT 2016, osModified=Feb 4 17:17, osSize=9320, mismatch=true}
> _14u3_29.del={name=_14u3_29.del, size=1244036, sizeStr=1.2 MB, modified=Thu
> Feb 04 16:37:35 GMT 2016, osModified=Feb 4 16:37, osSize=1244036,
> mismatch=false}
> _2akw.si={name=_2akw.si, size=252, sizeStr=252 B, modified=Thu Feb 04
> 16:37:07 GMT 2016, osModified=Feb 4 16:37, osSize=252, mismatch=false}
> _2akw.cfe={name=_2akw.cfe, size=224, sizeStr=224 B, modified=Thu Feb 04
> 16:37:07 GMT 2016, osModified=Feb 4 16:37, osSize=224, mismatch=false}
> _2akw.cfs={name=_2akw.cfs, size=4952761, sizeStr=5.0 MB, modified=Thu Feb 04
> 16:37:07 GMT 2016, osModified=Feb 4 16:37, osSize=4952761, mismatch=false}
> {noformat}
> And on same setup the system did saw a rollback in segment node store
> {noformat}
> -rw-rw-r--. 1 crx crx 25961984 Feb 4 16:47 data01357a.tar
> -rw-rw-r--. 1 crx crx 24385536 Feb 4 16:41 data01357a.tar.bak
> -rw-rw-r--. 1 crx crx359936 Feb 4 17:18
[jira] [Comment Edited] (OAK-4933) Create a data store implementation that integrates with Microsoft Azure Blob Storage
[ https://issues.apache.org/jira/browse/OAK-4933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15613028#comment-15613028 ] Matt Ryan edited comment on OAK-4933 at 10/27/16 7:57 PM: -- [~amjain] [jclouds|http://jclouds.apache.org/] does look interesting. An additional advantage I can see with jclouds is that classes aren't final so it should be mockable, which would make unit testing of cloud data stores and especially backends much better without relying on the existence of an account or network connectivity to execute the unit tests. Perhaps even better would be to implement a dummy blob store provider that executes all the actions locally, which would allow more thorough testing of this and future data stores (e.g. openstack like you mentioned). was (Author: mattvryan): [~amjain] (jclouds)[http://jclouds.apache.org/] does look interesting. An additional advantage I can see with jclouds is that classes aren't final so it should be mockable, which would make unit testing of cloud data stores and especially backends much better without relying on the existence of an account or network connectivity to execute the unit tests. Perhaps even better would be to implement a dummy blob store provider that executes all the actions locally, which would allow more thorough testing of this and future data stores (e.g. openstack like you mentioned). > Create a data store implementation that integrates with Microsoft Azure Blob > Storage > > > Key: OAK-4933 > URL: https://issues.apache.org/jira/browse/OAK-4933 > Project: Jackrabbit Oak > Issue Type: Epic > Components: blob, core >Reporter: Matt Ryan > > This epic proposes the creation of a new type of Oak data store, > AzureDataStore, that offers an integration between Oak and Microsoft Azure > Blob Storage. AzureDataStore would be very similar in purpose and > functionality to S3DataStore, with a different backend that uses Azure Blob > Storage instead of S3. > Some initial exploration into this concept can be seen in my github here: > https://github.com/mattvryan/jackrabbit-oak/tree/azure-blob-store > More info about Azure Blob Storage: > * [Java > SDK|https://azure.microsoft.com/en-us/documentation/articles/storage-java-how-to-use-blob-storage/] > * [Javadoc|http://azure.github.io/azure-storage-java/] > * [Source|https://github.com/azure/azure-storage-java] (GitHub) - Microsoft's > Azure Storage Java SDK is open source and Apache licensed > * [Package > info|https://mvnrepository.com/artifact/com.microsoft.azure/azure-storage] on > mvnrepository.com > As I see it, the following work would be required: > * Create an AzureDataStore class that extends CachingDataStore > * Create a new backend for Azure Blob Storage > * Comprehensive unit testing of the new data store and backend classes > * Create test "mocks" for the necessary Azure Storage classes to facilitate > unit testing (they are all final classes and cannot be mocked directly) > * Create SharedAzureDataStore class > * Create AzureDataStoreService class > * Implement similar JMX metrics as exist for S3DataStore > * Combine and refactor existing Oak code with newly added code to make best > reuse of existing code, etc. > * Integration testing with system configured with AzureDataStore, comparison > w/ S3DataStore in terms of performance and correctness > * Modify Azure Storage SDK code to make it into a valid OSGi bundle, and > submit these changes back to that project (currently it is not an OSGi bundle > and therefore currently has to be embedded) > List isn't purported to be comprehensive of course. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-5026) Enable default memory mapping for segment mode in oak-run console
[
https://issues.apache.org/jira/browse/OAK-5026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra resolved OAK-5026.
--
Resolution: Fixed
Fix Version/s: 1.5.13
Done with 1766820
> Enable default memory mapping for segment mode in oak-run console
> -
>
> Key: OAK-5026
> URL: https://issues.apache.org/jira/browse/OAK-5026
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: run
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: 1.6, 1.5.13
>
>
> When using old {{--segment=true}} mode the SegmentStore configured is not
> mmap enabled by default. The builder should use {{withDefaultMemoryMapping}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-5030) Copying the versions store is slow and increase the repository size
[
https://issues.apache.org/jira/browse/OAK-5030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig updated OAK-5030:
---
Attachment: OAK-5030.patch
Proposed patch: [^OAK-5030.patch].
The patch tracks the version storage node separately for the read only case.
With this the described use case runs in minutes vs. hours without increasing
the repository.
[~tomek.rekawek], please cross check and apply if this makes sense to you.
[~alex.parvulescu], this is the root cause of the slowness and growth we were
talking about.
> Copying the versions store is slow and increase the repository size
> ---
>
> Key: OAK-5030
> URL: https://issues.apache.org/jira/browse/OAK-5030
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: upgrade
>Reporter: Michael Dürig
> Labels: perfomance
> Fix For: 1.5.13
>
> Attachments: OAK-5030.patch
>
>
> This is a follow up to OAK-4970: when defining an workspace name that doesn't
> match the name of the workspace of the source repository (via the
> {{WORKSPACE_NAME_PROP}} system property), upgrading is still very slow and
> causes the repository size to grow way too much.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-5025) Speed up ACE node name generation
[
https://issues.apache.org/jira/browse/OAK-5025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated OAK-5025:
Labels: performance (was: )
> Speed up ACE node name generation
> -
>
> Key: OAK-5025
> URL: https://issues.apache.org/jira/browse/OAK-5025
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.5.12
>Reporter: Alex COLLIGNON
>Assignee: angela
>Priority: Minor
> Labels: performance
>
> Currently,
> {{o.a.j.oak.security.authorization.accesscontrol.Util#generateAceName}} is
> traversing all the existing ACE of a certain node in order to generate
> continuous numbering (allow0, allow1, allow2).
> While that certainly helps to produce human readable names, it represents
> quite a performance bottleneck when the number of existing ACE starts to grow.
> Since the naming is a pure implementation detail, my proposal is to keep the
> continuous numbering for the first hundreds of nodes and then use a random
> number to generate unique names in a faster fashion.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (OAK-5025) Speed up ACE node name generation
[
https://issues.apache.org/jira/browse/OAK-5025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15612385#comment-15612385
]
angela edited comment on OAK-5025 at 10/27/16 4:18 PM:
---
[~acollign], as discussed I will be happy to review and apply the patch you are
working on. just ping me once you are done. thanks a lot for the report and the
analysis.
was (Author: anchela):
[~acollign], as discussed I will be happy to review the patch you are working
on. just ping me once you are done. thanks a lot for the report and the
analysis.
> Speed up ACE node name generation
> -
>
> Key: OAK-5025
> URL: https://issues.apache.org/jira/browse/OAK-5025
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.5.12
>Reporter: Alex COLLIGNON
>Assignee: angela
>Priority: Minor
>
> Currently,
> {{o.a.j.oak.security.authorization.accesscontrol.Util#generateAceName}} is
> traversing all the existing ACE of a certain node in order to generate
> continuous numbering (allow0, allow1, allow2).
> While that certainly helps to produce human readable names, it represents
> quite a performance bottleneck when the number of existing ACE starts to grow.
> Since the naming is a pure implementation detail, my proposal is to keep the
> continuous numbering for the first hundreds of nodes and then use a random
> number to generate unique names in a faster fashion.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-5025) Speed up ACE node name generation
[
https://issues.apache.org/jira/browse/OAK-5025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15612385#comment-15612385
]
angela commented on OAK-5025:
-
[~acollign], as discussed I will be happy to review the patch you are working
on. just ping me once you are done. thanks a lot for the report and the
analysis.
> Speed up ACE node name generation
> -
>
> Key: OAK-5025
> URL: https://issues.apache.org/jira/browse/OAK-5025
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.5.12
>Reporter: Alex COLLIGNON
>Assignee: angela
>Priority: Minor
>
> Currently,
> {{o.a.j.oak.security.authorization.accesscontrol.Util#generateAceName}} is
> traversing all the existing ACE of a certain node in order to generate
> continuous numbering (allow0, allow1, allow2).
> While that certainly helps to produce human readable names, it represents
> quite a performance bottleneck when the number of existing ACE starts to grow.
> Since the naming is a pure implementation detail, my proposal is to keep the
> continuous numbering for the first hundreds of nodes and then use a random
> number to generate unique names in a faster fashion.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-5030) Copying the versions store is slow and increase the repository size
[
https://issues.apache.org/jira/browse/OAK-5030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15612389#comment-15612389
]
Michael Dürig commented on OAK-5030:
The reason for the slowness and the growth is how the {{versionStorage}} node
builder in {{VersionableEditor}} is used: its {{getNodeState()}} method is
called very frequently inside {{VersionableEditor.isVersionHistoryExists()}}.
This isn't the intended use case for node builders as their {{getNodeState()}}
method is not optimised for read performance and might have side effects. In
the case of the {{SegmentNodeBuilder}} it flushed pending changes to disk (thus
the growths and the slowness).
> Copying the versions store is slow and increase the repository size
> ---
>
> Key: OAK-5030
> URL: https://issues.apache.org/jira/browse/OAK-5030
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: upgrade
>Reporter: Michael Dürig
> Labels: perfomance
> Fix For: 1.5.13
>
>
> This is a follow up to OAK-4970: when defining an workspace name that doesn't
> match the name of the workspace of the source repository (via the
> {{WORKSPACE_NAME_PROP}} system property), upgrading is still very slow and
> causes the repository size to grow way too much.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (OAK-5025) Speed up ACE node name generation
[
https://issues.apache.org/jira/browse/OAK-5025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela reassigned OAK-5025:
---
Assignee: angela
> Speed up ACE node name generation
> -
>
> Key: OAK-5025
> URL: https://issues.apache.org/jira/browse/OAK-5025
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.5.12
>Reporter: Alex COLLIGNON
>Assignee: angela
>Priority: Minor
>
> Currently,
> {{o.a.j.oak.security.authorization.accesscontrol.Util#generateAceName}} is
> traversing all the existing ACE of a certain node in order to generate
> continuous numbering (allow0, allow1, allow2).
> While that certainly helps to produce human readable names, it represents
> quite a performance bottleneck when the number of existing ACE starts to grow.
> Since the naming is a pure implementation detail, my proposal is to keep the
> continuous numbering for the first hundreds of nodes and then use a random
> number to generate unique names in a faster fashion.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-5025) Speed up ACE node name generation
[
https://issues.apache.org/jira/browse/OAK-5025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated OAK-5025:
Component/s: (was: security)
core
> Speed up ACE node name generation
> -
>
> Key: OAK-5025
> URL: https://issues.apache.org/jira/browse/OAK-5025
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.5.12
>Reporter: Alex COLLIGNON
>Priority: Minor
>
> Currently,
> {{o.a.j.oak.security.authorization.accesscontrol.Util#generateAceName}} is
> traversing all the existing ACE of a certain node in order to generate
> continuous numbering (allow0, allow1, allow2).
> While that certainly helps to produce human readable names, it represents
> quite a performance bottleneck when the number of existing ACE starts to grow.
> Since the naming is a pure implementation detail, my proposal is to keep the
> continuous numbering for the first hundreds of nodes and then use a random
> number to generate unique names in a faster fashion.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-5030) Copying the versions store is slow and increase the repository size
Michael Dürig created OAK-5030:
--
Summary: Copying the versions store is slow and increase the
repository size
Key: OAK-5030
URL: https://issues.apache.org/jira/browse/OAK-5030
Project: Jackrabbit Oak
Issue Type: Improvement
Components: upgrade
Reporter: Michael Dürig
Fix For: 1.5.13
This is a follow up to OAK-4970: when defining an workspace name that doesn't
match the name of the workspace of the source repository (via the
{{WORKSPACE_NAME_PROP}} system property), upgrading is still very slow and
causes the repository size to grow way too much.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (OAK-5017) Standby test failures
[
https://issues.apache.org/jira/browse/OAK-5017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret reassigned OAK-5017:
---
Assignee: Timothee Maret
> Standby test failures
> -
>
> Key: OAK-5017
> URL: https://issues.apache.org/jira/browse/OAK-5017
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Reporter: Michael Dürig
>Assignee: Timothee Maret
> Labels: test-failure
> Fix For: 1.5.13
>
>
> I've recently seen a couple of the standby tests fail. E.g. on Jenkins:
> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/1245/
> {noformat}
> java.lang.AssertionError: expected:
> org.apache.jackrabbit.oak.segment.SegmentNodeState<{ checkpoints = { ... },
> root = { ... } }> but was:
> org.apache.jackrabbit.oak.segment.SegmentNodeState<{ checkpoints = { ... },
> root = { ... } }>
> at
> org.apache.jackrabbit.oak.segment.standby.StandbyTestIT.testSyncLoop(StandbyTestIT.java:122)
> {noformat}
> {noformat}
> java.lang.AssertionError: expected:
> org.apache.jackrabbit.oak.segment.SegmentNodeState<{ checkpoints = { ... },
> root = { ... } }> but was:
> org.apache.jackrabbit.oak.segment.SegmentNodeState<{ checkpoints = { ... },
> root = { ... } }>
> at
> org.apache.jackrabbit.oak.segment.standby.StandbyTestIT.testSyncLoop(StandbyTestIT.java:122)
> {noformat}
> {{org.apache.jackrabbit.oak.segment.standby.ExternalSharedStoreIT.testProxySkippedBytes}}:
> {noformat}
> java.lang.AssertionError: expected:<{ root = { ... } }> but was:<{ root : { }
> }>
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-5029) Use head GC generation number to trigger cleanup on standby instance
[
https://issues.apache.org/jira/browse/OAK-5029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15612268#comment-15612268
]
Timothee Maret commented on OAK-5029:
-
[~frm] could you have a look at the patch ?
> Use head GC generation number to trigger cleanup on standby instance
> -
>
> Key: OAK-5029
> URL: https://issues.apache.org/jira/browse/OAK-5029
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Affects Versions: Segment Tar 0.0.16
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Attachments: OAK-5029.patch
>
>
> With {{oak-segment-tar}}, the trigger for running {{cleanup}} on the standby
> instance could be determined by the GC generation number of the head which is
> bound to increase every time a cleanup is ran.
> {code}
> fileStore.getHead().getRecordId().getSegment().getGcGeneration();
> {code}
> The current trigger mechanism consists of detecting a 25% size increase over
> a client cycle (typ. 5 sec).
> This would be dropped in favor of the new detection mechanism.
> The auto-compaction mode would remain configurable.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-5029) Use head GC generation number to trigger cleanup on standby instance
[
https://issues.apache.org/jira/browse/OAK-5029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret updated OAK-5029:
Attachment: OAK-5029.patch
Attaching a svn compatible patch, otherwise available at
https://github.com/tmaret/jackrabbit-oak/commit/aa421e549b5b150d56ebd32a6534fe2a432e2fa1
The patch does
1. Change the mechanism to trigger cleanup on standby instance, use the head
segment gc generation number
2. Update the {{standby.autoclean}} OSGI description to reflect the change
> Use head GC generation number to trigger cleanup on standby instance
> -
>
> Key: OAK-5029
> URL: https://issues.apache.org/jira/browse/OAK-5029
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Affects Versions: Segment Tar 0.0.16
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Attachments: OAK-5029.patch
>
>
> With {{oak-segment-tar}}, the trigger for running {{cleanup}} on the standby
> instance could be determined by the GC generation number of the head which is
> bound to increase every time a cleanup is ran.
> {code}
> fileStore.getHead().getRecordId().getSegment().getGcGeneration();
> {code}
> The current trigger mechanism consists of detecting a 25% size increase over
> a client cycle (typ. 5 sec).
> This would be dropped in favor of the new detection mechanism.
> The auto-compaction mode would remain configurable.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-5029) Use head GC generation number to trigger cleanup on standby instance
[
https://issues.apache.org/jira/browse/OAK-5029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret updated OAK-5029:
Flags: Patch
> Use head GC generation number to trigger cleanup on standby instance
> -
>
> Key: OAK-5029
> URL: https://issues.apache.org/jira/browse/OAK-5029
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Affects Versions: Segment Tar 0.0.16
>Reporter: Timothee Maret
>Assignee: Timothee Maret
> Attachments: OAK-5029.patch
>
>
> With {{oak-segment-tar}}, the trigger for running {{cleanup}} on the standby
> instance could be determined by the GC generation number of the head which is
> bound to increase every time a cleanup is ran.
> {code}
> fileStore.getHead().getRecordId().getSegment().getGcGeneration();
> {code}
> The current trigger mechanism consists of detecting a 25% size increase over
> a client cycle (typ. 5 sec).
> This would be dropped in favor of the new detection mechanism.
> The auto-compaction mode would remain configurable.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4932) DefaultSyncContext.sync(String) could use idp.getIdentity(ExternalIdentityRef)
[
https://issues.apache.org/jira/browse/OAK-4932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15612132#comment-15612132
]
Alexander Klimetschek commented on OAK-4932:
But now that OAK-4301 is fixed, it is safe.
One can add a warning that disabling the protection will disable the protection
:-) Do we know if there is a good reason for customers to always disable the
protection?
Last but not least one could make it dependent on the protection what to call
(and document).
IMO conceptually the local user id belongs into the sync (i.e. what maps from
external to local), and not in the external IDP, which is just declaratively
representing the external system.
> DefaultSyncContext.sync(String) could use idp.getIdentity(ExternalIdentityRef)
> --
>
> Key: OAK-4932
> URL: https://issues.apache.org/jira/browse/OAK-4932
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: auth-external
>Reporter: Alexander Klimetschek
>
> Instead of
> [idp.getGroup(id)|https://github.com/apache/jackrabbit-oak/blob/08aadf19a5e6b1bb4ca6687623e06140fb1ec5bc/oak-auth-external/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/external/basic/DefaultSyncContext.java#L291]
> and
> [idp.getUser(id)|https://github.com/apache/jackrabbit-oak/blob/08aadf19a5e6b1bb4ca6687623e06140fb1ec5bc/oak-auth-external/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/external/basic/DefaultSyncContext.java#L300],
> the implementation of the DefaultSyncHandler could use
> {{ExternalIdentityProvider.getIdentity(ExternalIdentityRef)}}, as it looks up
> the reference right before (based on the {{rep:externalId}}) and fails if not
> present.
> h4. Reasoning
> Implementing {{getUser/Group(id)}} in an ExternalIdentityProvider can be
> difficult, because you need a way to search the external identity system
> efficiently by the local user id, which might not always be the case, if the
> external system uses another id and is only optimized for that.
> h4. Consequences
> # The only other place using {{ExternalIdentityProvider.getUser(String)}} is
> the
> [ExternalLoginModule|https://github.com/apache/jackrabbit-oak/blob/52f1e9a84324135e6a79678bbf209d03c0d2d77d/oak-auth-external/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/external/impl/ExternalLoginModule.java#L217],
> in case the user is pre-authenticated and does not exist locally yet.
> However, this is a specific use case that might not apply to all identity
> providers, in which case they could happily skip implementing this method. A
> note in the javadoc could clarify this for implementors.
> # {{ExternalIdentityProvider.getGroup(String)}} would then be used in no
> other place (in the sync code) and could even be deprecated, as I can't
> imagine another application specific use case for it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-5029) Use head GC generation number to trigger cleanup on standby instance
[
https://issues.apache.org/jira/browse/OAK-5029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret updated OAK-5029:
Description:
With {{oak-segment-tar}}, the trigger for running {{cleanup}} on the standby
instance could be determined by the GC generation number of the head which is
bound to increase every time a cleanup is ran.
{code}
fileStore.getHead().getRecordId().getSegment().getGcGeneration();
{code}
The current trigger mechanism consists of detecting a 25% size increase over a
client cycle (typ. 5 sec).
This would be dropped in favor of the new detection mechanism.
The auto-compaction mode would remain configurable.
was:
With {{oak-segment-tar}}, the trigger for running {{cleanup}} on the standby
instance could be determined by the GC generation number of the head which is
bound to increase every time a cleanup is ran.
{code}
fileStore.getHead().getRecordId().getSegment().getGcGeneration();
{code}
> Use head GC generation number to trigger cleanup on standby instance
> -
>
> Key: OAK-5029
> URL: https://issues.apache.org/jira/browse/OAK-5029
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Affects Versions: Segment Tar 0.0.16
>Reporter: Timothee Maret
>Assignee: Timothee Maret
>
> With {{oak-segment-tar}}, the trigger for running {{cleanup}} on the standby
> instance could be determined by the GC generation number of the head which is
> bound to increase every time a cleanup is ran.
> {code}
> fileStore.getHead().getRecordId().getSegment().getGcGeneration();
> {code}
> The current trigger mechanism consists of detecting a 25% size increase over
> a client cycle (typ. 5 sec).
> This would be dropped in favor of the new detection mechanism.
> The auto-compaction mode would remain configurable.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-5029) Use head GC generation number to trigger cleanup on standby instance
Timothee Maret created OAK-5029:
---
Summary: Use head GC generation number to trigger cleanup on
standby instance
Key: OAK-5029
URL: https://issues.apache.org/jira/browse/OAK-5029
Project: Jackrabbit Oak
Issue Type: Improvement
Components: segment-tar
Affects Versions: Segment Tar 0.0.16
Reporter: Timothee Maret
Assignee: Timothee Maret
With {{oak-segment-tar}}, the trigger for running {{cleanup}} on the standby
instance could be determined by the GC generation number of the head which is
bound to increase every time a cleanup is ran.
{code}
fileStore.getHead().getRecordId().getSegment().getGcGeneration();
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-5028) Remove DocumentStore.update()
Marcel Reutegger created OAK-5028: - Summary: Remove DocumentStore.update() Key: OAK-5028 URL: https://issues.apache.org/jira/browse/OAK-5028 Project: Jackrabbit Oak Issue Type: Task Components: core, documentmk, mongomk, rdbmk Reporter: Marcel Reutegger Assignee: Marcel Reutegger Fix For: 1.6 OAK-3018 removed the single production usage of DocumentStore.update(). I propose we remove the method to reduce maintenance. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3018) Use batch-update in backgroundWrite
[
https://issues.apache.org/jira/browse/OAK-3018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger updated OAK-3018:
--
Component/s: (was: mongomk)
documentmk
core
> Use batch-update in backgroundWrite
> ---
>
> Key: OAK-3018
> URL: https://issues.apache.org/jira/browse/OAK-3018
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, documentmk
>Reporter: Stefan Egli
>Assignee: Marcel Reutegger
> Labels: performance
> Fix For: 1.6, 1.5.13
>
>
> (From an earlier [post on the
> list|http://markmail.org/thread/mkrvhkfabit4osli]) The
> DocumentNodeStore.backgroundWrite goes through the heavy work of updating the
> lastRev for all pending changes and does so in a hierarchical-depth-first
> manner. Unfortunately, if the pending changes all come from separate commits
> (as does not sound so unlikely), the updates are sent in individual update
> calls to mongo (whenever the lastRev differs). Which, if there are many
> changes, results in many calls to mongo.
> OAK-2066 is about extending the DocumentStore API with a batch-update method.
> That one, once available, should thus be used in the {{backgroundWrite}} as
> well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-3018) Use batch-update in backgroundWrite
[
https://issues.apache.org/jira/browse/OAK-3018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger resolved OAK-3018.
---
Resolution: Fixed
Fix Version/s: 1.5.13
Implemented in trunk: http://svn.apache.org/r1766838
> Use batch-update in backgroundWrite
> ---
>
> Key: OAK-3018
> URL: https://issues.apache.org/jira/browse/OAK-3018
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, documentmk
>Reporter: Stefan Egli
>Assignee: Marcel Reutegger
> Labels: performance
> Fix For: 1.6, 1.5.13
>
>
> (From an earlier [post on the
> list|http://markmail.org/thread/mkrvhkfabit4osli]) The
> DocumentNodeStore.backgroundWrite goes through the heavy work of updating the
> lastRev for all pending changes and does so in a hierarchical-depth-first
> manner. Unfortunately, if the pending changes all come from separate commits
> (as does not sound so unlikely), the updates are sent in individual update
> calls to mongo (whenever the lastRev differs). Which, if there are many
> changes, results in many calls to mongo.
> OAK-2066 is about extending the DocumentStore API with a batch-update method.
> That one, once available, should thus be used in the {{backgroundWrite}} as
> well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-5027) Test utils for commonly used functionality
[ https://issues.apache.org/jira/browse/OAK-5027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved OAK-5027. --- Resolution: Fixed Fix Version/s: 1.5.13 Done in trunk: http://svn.apache.org/r1766836 > Test utils for commonly used functionality > -- > > Key: OAK-5027 > URL: https://issues.apache.org/jira/browse/OAK-5027 > Project: Jackrabbit Oak > Issue Type: Test > Components: core >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Fix For: 1.6, 1.5.13 > > > Introduce a utility class with functionality commonly used in tests. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-5027) Test utils for commonly used functionality
Marcel Reutegger created OAK-5027: - Summary: Test utils for commonly used functionality Key: OAK-5027 URL: https://issues.apache.org/jira/browse/OAK-5027 Project: Jackrabbit Oak Issue Type: Test Components: core Reporter: Marcel Reutegger Assignee: Marcel Reutegger Priority: Minor Fix For: 1.6 Introduce a utility class with functionality commonly used in tests. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-5026) Enable default memory mapping for segment mode in oak-run console
Chetan Mehrotra created OAK-5026:
Summary: Enable default memory mapping for segment mode in oak-run
console
Key: OAK-5026
URL: https://issues.apache.org/jira/browse/OAK-5026
Project: Jackrabbit Oak
Issue Type: Improvement
Components: run
Reporter: Chetan Mehrotra
Assignee: Chetan Mehrotra
Priority: Minor
Fix For: 1.6
When using old {{--segment=true}} mode the SegmentStore configured is not mmap
enabled by default. The builder should use {{withDefaultMemoryMapping}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-5025) Speed up ACE node name generation
[
https://issues.apache.org/jira/browse/OAK-5025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex COLLIGNON updated OAK-5025:
Priority: Minor (was: Major)
> Speed up ACE node name generation
> -
>
> Key: OAK-5025
> URL: https://issues.apache.org/jira/browse/OAK-5025
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: security
>Affects Versions: 1.5.12
>Reporter: Alex COLLIGNON
>Priority: Minor
>
> Currently,
> {{o.a.j.oak.security.authorization.accesscontrol.Util#generateAceName}} is
> traversing all the existing ACE of a certain node in order to generate
> continuous numbering (allow0, allow1, allow2).
> While that certainly helps to produce human readable names, it represents
> quite a performance bottleneck when the number of existing ACE starts to grow.
> Since the naming is a pure implementation detail, my proposal is to keep the
> continuous numbering for the first hundreds of nodes and then use a random
> number to generate unique names in a faster fashion.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-5025) Speed up ACE node name generation
Alex COLLIGNON created OAK-5025:
---
Summary: Speed up ACE node name generation
Key: OAK-5025
URL: https://issues.apache.org/jira/browse/OAK-5025
Project: Jackrabbit Oak
Issue Type: Improvement
Components: security
Affects Versions: 1.5.12
Reporter: Alex COLLIGNON
Currently,
{{o.a.j.oak.security.authorization.accesscontrol.Util#generateAceName}} is
traversing all the existing ACE of a certain node in order to generate
continuous numbering (allow0, allow1, allow2).
While that certainly helps to produce human readable names, it represents quite
a performance bottleneck when the number of existing ACE starts to grow.
Since the naming is a pure implementation detail, my proposal is to keep the
continuous numbering for the first hundreds of nodes and then use a random
number to generate unique names in a faster fashion.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-5018) Warn traversal queries: false positives
[
https://issues.apache.org/jira/browse/OAK-5018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15611655#comment-15611655
]
Thomas Mueller commented on OAK-5018:
-
http://svn.apache.org/r1766810 (trunk) - avoid false positives for single node
queries, and queries that iterate over just direct child nodes
> Warn traversal queries: false positives
> ---
>
> Key: OAK-5018
> URL: https://issues.apache.org/jira/browse/OAK-5018
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: query
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
> Fix For: 1.5.13
>
>
> OAK-4888 logs a warning by default if there are queries that traverse. There
> are false positives, for example if "ischildnode" is used:
> {noformat}
> /jcr:root/content/*/jcr:content[@xyz]
> {noformat}
> This needs to be fixed.
> Temporarily, I will change the "warn" to "info" until this is resolved.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-5018) Warn traversal queries: false positives
[
https://issues.apache.org/jira/browse/OAK-5018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller updated OAK-5018:
Component/s: query
> Warn traversal queries: false positives
> ---
>
> Key: OAK-5018
> URL: https://issues.apache.org/jira/browse/OAK-5018
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: query
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
> Fix For: 1.5.13
>
>
> OAK-4888 logs a warning by default if there are queries that traverse. There
> are false positives, for example if "ischildnode" is used:
> {noformat}
> /jcr:root/content/*/jcr:content[@xyz]
> {noformat}
> This needs to be fixed.
> Temporarily, I will change the "warn" to "info" until this is resolved.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-5018) Warn traversal queries: false positives
[
https://issues.apache.org/jira/browse/OAK-5018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller updated OAK-5018:
Fix Version/s: 1.5.13
> Warn traversal queries: false positives
> ---
>
> Key: OAK-5018
> URL: https://issues.apache.org/jira/browse/OAK-5018
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: query
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
> Fix For: 1.5.13
>
>
> OAK-4888 logs a warning by default if there are queries that traverse. There
> are false positives, for example if "ischildnode" is used:
> {noformat}
> /jcr:root/content/*/jcr:content[@xyz]
> {noformat}
> This needs to be fixed.
> Temporarily, I will change the "warn" to "info" until this is resolved.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-5024) Improve the usage of the SegmentWriter for compaction
[
https://issues.apache.org/jira/browse/OAK-5024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig updated OAK-5024:
---
Attachment: OAK-5024.patch
Proposed patch: [^OAK-5024.patch].
[~alex.parvulescu], [~frm] WDYT?
> Improve the usage of the SegmentWriter for compaction
> -
>
> Key: OAK-5024
> URL: https://issues.apache.org/jira/browse/OAK-5024
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Reporter: Michael Dürig
>Assignee: Michael Dürig
> Labels: refactoring
> Fix For: 1.5.13
>
> Attachments: OAK-5024.patch
>
>
> I would like to improve how the {{SegmentWriter}} is used for compaction. In
> particular I dislike how the {{SegmentBufferWriter}} needs to be looped into
> {{SegmentWriter.writeNode()}}.
> Furthermore creating a {{SegmentWriter}} for offline compaction with its own
> cache (instead of using the caches we have) is a bit wasteful wrt. to memory.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-5024) Improve the usage of the SegmentWriter for compaction
Michael Dürig created OAK-5024:
--
Summary: Improve the usage of the SegmentWriter for compaction
Key: OAK-5024
URL: https://issues.apache.org/jira/browse/OAK-5024
Project: Jackrabbit Oak
Issue Type: Improvement
Components: segment-tar
Reporter: Michael Dürig
Assignee: Michael Dürig
Fix For: 1.5.13
I would like to improve how the {{SegmentWriter}} is used for compaction. In
particular I dislike how the {{SegmentBufferWriter}} needs to be looped into
{{SegmentWriter.writeNode()}}.
Furthermore creating a {{SegmentWriter}} for offline compaction with its own
cache (instead of using the caches we have) is a bit wasteful wrt. to memory.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-2423) Add PermissionProvider.canRead
[
https://issues.apache.org/jira/browse/OAK-2423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela resolved OAK-2423.
-
Resolution: Later
> Add PermissionProvider.canRead
> --
>
> Key: OAK-2423
> URL: https://issues.apache.org/jira/browse/OAK-2423
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Reporter: angela
>Assignee: angela
>Priority: Minor
> Attachments: OAK-2423.patch
>
>
> As discussed with [~tmueller] and [~teofili], it might be beneficial for
> query performance if it was possible to determine read-access without having
> to create the {{Tree}} (and thus the hierarchy). The latter (as present with
> {{TreePermission.canRead}}) is suited for regular repository read operations
> where the tree hierarchy is built anyway.
> since {{PermissionProvider.isGranted(String oakPath, String jcrActions)}}
> requires to resolve the path to properly deal with write operations, i would
> suggest to evaluate if adding {{PermissionProvider.canRead(@Nonnull String
> treePath, @Nullable String propertyName}} would give us some performance gain
> in the query case.
> initial (untested) draft attached for basic evaluation. proper unit and
> benchmark testing are required.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4696) Improve logging for SyncHandler
[
https://issues.apache.org/jira/browse/OAK-4696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated OAK-4696:
Issue Type: Improvement (was: Bug)
> Improve logging for SyncHandler
> ---
>
> Key: OAK-4696
> URL: https://issues.apache.org/jira/browse/OAK-4696
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: auth-external
>Affects Versions: 1.5.8
>Reporter: Konrad Windszus
>Assignee: angela
>
> In the {{ExternalLoginModule.syncUser}} the {{context.sync(..)}} is being
> called without evaluating the return value at all
> (https://github.com/apache/jackrabbit-oak/blob/trunk/oak-auth-external/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/external/impl/ExternalLoginModule.java#L354).
> The return value should be logged to find out, which sync took place.
> Also I am wondering if it would make sense to do the {{root.commit()}} only
> conditionally in case the return value is not {{SyncResult.NOP}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (OAK-4932) DefaultSyncContext.sync(String) could use idp.getIdentity(ExternalIdentityRef)
[
https://issues.apache.org/jira/browse/OAK-4932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela closed OAK-4932.
---
> DefaultSyncContext.sync(String) could use idp.getIdentity(ExternalIdentityRef)
> --
>
> Key: OAK-4932
> URL: https://issues.apache.org/jira/browse/OAK-4932
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: auth-external
>Reporter: Alexander Klimetschek
>
> Instead of
> [idp.getGroup(id)|https://github.com/apache/jackrabbit-oak/blob/08aadf19a5e6b1bb4ca6687623e06140fb1ec5bc/oak-auth-external/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/external/basic/DefaultSyncContext.java#L291]
> and
> [idp.getUser(id)|https://github.com/apache/jackrabbit-oak/blob/08aadf19a5e6b1bb4ca6687623e06140fb1ec5bc/oak-auth-external/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/external/basic/DefaultSyncContext.java#L300],
> the implementation of the DefaultSyncHandler could use
> {{ExternalIdentityProvider.getIdentity(ExternalIdentityRef)}}, as it looks up
> the reference right before (based on the {{rep:externalId}}) and fails if not
> present.
> h4. Reasoning
> Implementing {{getUser/Group(id)}} in an ExternalIdentityProvider can be
> difficult, because you need a way to search the external identity system
> efficiently by the local user id, which might not always be the case, if the
> external system uses another id and is only optimized for that.
> h4. Consequences
> # The only other place using {{ExternalIdentityProvider.getUser(String)}} is
> the
> [ExternalLoginModule|https://github.com/apache/jackrabbit-oak/blob/52f1e9a84324135e6a79678bbf209d03c0d2d77d/oak-auth-external/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/external/impl/ExternalLoginModule.java#L217],
> in case the user is pre-authenticated and does not exist locally yet.
> However, this is a specific use case that might not apply to all identity
> providers, in which case they could happily skip implementing this method. A
> note in the javadoc could clarify this for implementors.
> # {{ExternalIdentityProvider.getGroup(String)}} would then be used in no
> other place (in the sync code) and could even be deprecated, as I can't
> imagine another application specific use case for it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-4932) DefaultSyncContext.sync(String) could use idp.getIdentity(ExternalIdentityRef)
[
https://issues.apache.org/jira/browse/OAK-4932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela resolved OAK-4932.
-
Resolution: Won't Fix
> DefaultSyncContext.sync(String) could use idp.getIdentity(ExternalIdentityRef)
> --
>
> Key: OAK-4932
> URL: https://issues.apache.org/jira/browse/OAK-4932
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: auth-external
>Reporter: Alexander Klimetschek
>
> Instead of
> [idp.getGroup(id)|https://github.com/apache/jackrabbit-oak/blob/08aadf19a5e6b1bb4ca6687623e06140fb1ec5bc/oak-auth-external/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/external/basic/DefaultSyncContext.java#L291]
> and
> [idp.getUser(id)|https://github.com/apache/jackrabbit-oak/blob/08aadf19a5e6b1bb4ca6687623e06140fb1ec5bc/oak-auth-external/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/external/basic/DefaultSyncContext.java#L300],
> the implementation of the DefaultSyncHandler could use
> {{ExternalIdentityProvider.getIdentity(ExternalIdentityRef)}}, as it looks up
> the reference right before (based on the {{rep:externalId}}) and fails if not
> present.
> h4. Reasoning
> Implementing {{getUser/Group(id)}} in an ExternalIdentityProvider can be
> difficult, because you need a way to search the external identity system
> efficiently by the local user id, which might not always be the case, if the
> external system uses another id and is only optimized for that.
> h4. Consequences
> # The only other place using {{ExternalIdentityProvider.getUser(String)}} is
> the
> [ExternalLoginModule|https://github.com/apache/jackrabbit-oak/blob/52f1e9a84324135e6a79678bbf209d03c0d2d77d/oak-auth-external/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/external/impl/ExternalLoginModule.java#L217],
> in case the user is pre-authenticated and does not exist locally yet.
> However, this is a specific use case that might not apply to all identity
> providers, in which case they could happily skip implementing this method. A
> note in the javadoc could clarify this for implementors.
> # {{ExternalIdentityProvider.getGroup(String)}} would then be used in no
> other place (in the sync code) and could even be deprecated, as I can't
> imagine another application specific use case for it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4932) DefaultSyncContext.sync(String) could use idp.getIdentity(ExternalIdentityRef)
[
https://issues.apache.org/jira/browse/OAK-4932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15611267#comment-15611267
]
angela commented on OAK-4932:
-
[~alexander.klimetschek], the proposed (minor) changes it exactly what i was
pointing to in OAK-4301; doing so would result in allow in the missing
protection resulting a critical vulnerability. we were just lucky that OAK-4301
could not be exploited. so, I don't thing that we should make that change given
the fact that some customers might need to disable the protected added with
OAK-4301 for other reasons.
for the record here the translation of a private conversation I had with
[~tripod]
{quote}
fortunately the external id reference isn't used to retrieve the
ExternalIdentity, which currently is read from the id (see ExternalUser
external = idp.getUser(id);). However, If i would change that particular line
to ExternalUser external = (ExternalUser) idp.getIdentity(ref) which IMHO was
equally legitimate and maybe even favorable, the worst case scenario would come
true and we had a really dangerous exploit.
{quote}
> DefaultSyncContext.sync(String) could use idp.getIdentity(ExternalIdentityRef)
> --
>
> Key: OAK-4932
> URL: https://issues.apache.org/jira/browse/OAK-4932
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: auth-external
>Reporter: Alexander Klimetschek
>
> Instead of
> [idp.getGroup(id)|https://github.com/apache/jackrabbit-oak/blob/08aadf19a5e6b1bb4ca6687623e06140fb1ec5bc/oak-auth-external/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/external/basic/DefaultSyncContext.java#L291]
> and
> [idp.getUser(id)|https://github.com/apache/jackrabbit-oak/blob/08aadf19a5e6b1bb4ca6687623e06140fb1ec5bc/oak-auth-external/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/external/basic/DefaultSyncContext.java#L300],
> the implementation of the DefaultSyncHandler could use
> {{ExternalIdentityProvider.getIdentity(ExternalIdentityRef)}}, as it looks up
> the reference right before (based on the {{rep:externalId}}) and fails if not
> present.
> h4. Reasoning
> Implementing {{getUser/Group(id)}} in an ExternalIdentityProvider can be
> difficult, because you need a way to search the external identity system
> efficiently by the local user id, which might not always be the case, if the
> external system uses another id and is only optimized for that.
> h4. Consequences
> # The only other place using {{ExternalIdentityProvider.getUser(String)}} is
> the
> [ExternalLoginModule|https://github.com/apache/jackrabbit-oak/blob/52f1e9a84324135e6a79678bbf209d03c0d2d77d/oak-auth-external/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/external/impl/ExternalLoginModule.java#L217],
> in case the user is pre-authenticated and does not exist locally yet.
> However, this is a specific use case that might not apply to all identity
> providers, in which case they could happily skip implementing this method. A
> note in the javadoc could clarify this for implementors.
> # {{ExternalIdentityProvider.getGroup(String)}} would then be used in no
> other place (in the sync code) and could even be deprecated, as I can't
> imagine another application specific use case for it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-5023) add applyOnOwnNode property to OakEventFilter
[
https://issues.apache.org/jira/browse/OAK-5023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Egli updated OAK-5023:
-
Description:
(Originally reported as JCR-4048, but moved to Oak as a result of introducing
the OakEventFilter in OAK-5013. From the original description: )
There seems to be a rather frequent use case of observation around which would
like to create a filter on a _child_ rather than on a _parent_: consider the
case when you'd like to filter for the removal of a node that has a particular
nodeType. This can't be achieved atm as the nodeType is applicable to the
parent of the node that changes, not the node itself (ie child).
Therefore suggesting the introduction of a flag similar to the following:
{code}
boolean applyOnOwnNode;
{code}
was:
There seems to be a rather frequent use case of observation around which would
like to create a filter on a _child_ rather than on a _parent_: consider the
case when you'd like to filter for the removal of a node that has a particular
nodeType. This can't be achieved atm as the nodeType is applicable to the
parent of the node that changes, not the node itself (ie child).
Therefore suggesting the introduction of a flag similar to the following:
{code}
boolean applyOnOwnNode;
{code}
> add applyOnOwnNode property to OakEventFilter
> -
>
> Key: OAK-5023
> URL: https://issues.apache.org/jira/browse/OAK-5023
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: jcr
>Affects Versions: 1.5.12
>Reporter: Stefan Egli
>Assignee: Stefan Egli
>
> (Originally reported as JCR-4048, but moved to Oak as a result of introducing
> the OakEventFilter in OAK-5013. From the original description: )
> There seems to be a rather frequent use case of observation around which
> would like to create a filter on a _child_ rather than on a _parent_:
> consider the case when you'd like to filter for the removal of a node that
> has a particular nodeType. This can't be achieved atm as the nodeType is
> applicable to the parent of the node that changes, not the node itself (ie
> child).
> Therefore suggesting the introduction of a flag similar to the following:
> {code}
> boolean applyOnOwnNode;
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-5023) add applyOnOwnNode property to OakEventFilter
Stefan Egli created OAK-5023:
Summary: add applyOnOwnNode property to OakEventFilter
Key: OAK-5023
URL: https://issues.apache.org/jira/browse/OAK-5023
Project: Jackrabbit Oak
Issue Type: Improvement
Components: jcr
Affects Versions: 1.5.12
Reporter: Stefan Egli
Assignee: Stefan Egli
There seems to be a rather frequent use case of observation around which would
like to create a filter on a _child_ rather than on a _parent_: consider the
case when you'd like to filter for the removal of a node that has a particular
nodeType. This can't be achieved atm as the nodeType is applicable to the
parent of the node that changes, not the node itself (ie child).
Therefore suggesting the introduction of a flag similar to the following:
{code}
boolean applyOnOwnNode;
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-5022) add includeSubtreeOnDelete flag to OakEventFilter
Stefan Egli created OAK-5022:
Summary: add includeSubtreeOnDelete flag to OakEventFilter
Key: OAK-5022
URL: https://issues.apache.org/jira/browse/OAK-5022
Project: Jackrabbit Oak
Issue Type: Improvement
Components: jcr
Affects Versions: 1.5.12
Reporter: Stefan Egli
Assignee: Stefan Egli
(Originally reported as JCR-4037, but moved to Oak as a result of introducing
the OakEventFilter in OAK-5013. From the original description: )
In some cases of observation it would be useful to receive events of child node
or properties of a parent/grandparent that was deleted. Currently (in Oak at
least) one only receives a deleted event for the node that was deleted and none
of the children.
Suggesting to (re)introduce a flag, eg as follows to the JackrabbitEventFilter:
{code}
boolean includeSubtreeOnRemove;
{code}
(Open for any better name of course)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-5021) Improve observation of files
Stefan Egli created OAK-5021: Summary: Improve observation of files Key: OAK-5021 URL: https://issues.apache.org/jira/browse/OAK-5021 Project: Jackrabbit Oak Issue Type: Improvement Components: jcr Affects Versions: 1.5.12 Reporter: Stefan Egli Assignee: Stefan Egli (Originally reported as JCR-4046, but moved to Oak as a result of introducing the OakEventFilter in OAK-5013. From the original description: ) A file in JCR is represented by at least two nodes, the nt:file node and a child node named jcr:content holding the contents of the file (and metadata). This has the consequence that if the contents of a file changes, a change event of the jcr:content node is reported - but not of the nt:file node. This makes creating listeners listening for changes in files complicated, as you can't use the file name to filter - especially with glob patterns (see JCR-4044 - now OAK-5019) this becomes troublesome. In addition, whenever you get a change for a jcr:content node, you have to check if the parent is a nt:file node and decide based on the result. It would be great to have a flag on the JackrabbitEventFilter to enable smarter reporting just for nt:files: if a property on jcr:content is changed, a change to the nt:file node is reported. See also SLING-6163 and OAK-4940 /cc [~cziegeler] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-5020) Improved support for node removals
Stefan Egli created OAK-5020: Summary: Improved support for node removals Key: OAK-5020 URL: https://issues.apache.org/jira/browse/OAK-5020 Project: Jackrabbit Oak Issue Type: Improvement Components: jcr Affects Versions: 1.5.12 Reporter: Stefan Egli Assignee: Stefan Egli (Originally reported as JCR-4045, but moved to Oak as a result of introducing the OakEventFilter in OAK-5013. From the original description: ) If a listener is subscribed for removal events of a subtree, e.g. /a/b/c/d it gets removal events for everything in that three. However, if /a/b is removed, the listener is not informed at all, which makes the listener state inconsistent/invalid I suggest to add a new flag to the JackrabbitEventFilter and if that is enabled the listener will get remove events of all the parent nodes - if the listener is interested in remove events of any kind. /cc [~cziegeler] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-5018) Warn traversal queries: false positives
[
https://issues.apache.org/jira/browse/OAK-5018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15611211#comment-15611211
]
Thomas Mueller commented on OAK-5018:
-
http://svn.apache.org/r1766784 (trunk) - change "warn" message to "info"
> Warn traversal queries: false positives
> ---
>
> Key: OAK-5018
> URL: https://issues.apache.org/jira/browse/OAK-5018
> Project: Jackrabbit Oak
> Issue Type: Bug
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>
> OAK-4888 logs a warning by default if there are queries that traverse. There
> are false positives, for example if "ischildnode" is used:
> {noformat}
> /jcr:root/content/*/jcr:content[@xyz]
> {noformat}
> This needs to be fixed.
> Temporarily, I will change the "warn" to "info" until this is resolved.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-5019) Support glob patterns through OakEventFilter
[ https://issues.apache.org/jira/browse/OAK-5019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Egli updated OAK-5019: - Description: (Originally reported as JCR-4044, but moved to Oak as a result of introducing the OakEventFilter in OAK-5013. From the original description: ) In the Sling project, we would like to register JCR listeners based on glob patterns as defined in https://jackrabbit.apache.org/oak/docs/apidocs/org/apache/jackrabbit/oak/plugins/observation/filter/GlobbingPathFilter.html So basically instead (or in addition) to specifying an absolute path, defining patterns. [Discussion thread|https://lists.apache.org/thread.html/300f84574bbb039cebe35aab1afc21e043560a1c0471e456a2f5c0be@%3Cdev.jackrabbit.apache.org%3E] /cc [~cziegeler] was: (Originally reported as JCR-4044, but moved to Oak as a result of introducing the OakEventFilter in OAK-5013. From the original description:) In the Sling project, we would like to register JCR listeners based on glob patterns as defined in https://jackrabbit.apache.org/oak/docs/apidocs/org/apache/jackrabbit/oak/plugins/observation/filter/GlobbingPathFilter.html So basically instead (or in addition) to specifying an absolute path, defining patterns. [Discussion thread|https://lists.apache.org/thread.html/300f84574bbb039cebe35aab1afc21e043560a1c0471e456a2f5c0be@%3Cdev.jackrabbit.apache.org%3E] /cc [~cziegeler] > Support glob patterns through OakEventFilter > > > Key: OAK-5019 > URL: https://issues.apache.org/jira/browse/OAK-5019 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: jcr >Affects Versions: 1.5.12 >Reporter: Stefan Egli >Assignee: Stefan Egli > > (Originally reported as JCR-4044, but moved to Oak as a result of introducing > the OakEventFilter in OAK-5013. From the original description: ) > In the Sling project, we would like to register JCR listeners based on glob > patterns as defined in > https://jackrabbit.apache.org/oak/docs/apidocs/org/apache/jackrabbit/oak/plugins/observation/filter/GlobbingPathFilter.html > So basically instead (or in addition) to specifying an absolute path, > defining patterns. > [Discussion > thread|https://lists.apache.org/thread.html/300f84574bbb039cebe35aab1afc21e043560a1c0471e456a2f5c0be@%3Cdev.jackrabbit.apache.org%3E] > /cc [~cziegeler] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-5019) Support glob patterns through OakEventFilter
Stefan Egli created OAK-5019: Summary: Support glob patterns through OakEventFilter Key: OAK-5019 URL: https://issues.apache.org/jira/browse/OAK-5019 Project: Jackrabbit Oak Issue Type: Improvement Components: jcr Affects Versions: 1.5.12 Reporter: Stefan Egli Assignee: Stefan Egli (Originally reported as JCR-4044, but moved to Oak as a result of introducing the OakEventFilter in OAK-5013. From the original description:) In the Sling project, we would like to register JCR listeners based on glob patterns as defined in https://jackrabbit.apache.org/oak/docs/apidocs/org/apache/jackrabbit/oak/plugins/observation/filter/GlobbingPathFilter.html So basically instead (or in addition) to specifying an absolute path, defining patterns. [Discussion thread|https://lists.apache.org/thread.html/300f84574bbb039cebe35aab1afc21e043560a1c0471e456a2f5c0be@%3Cdev.jackrabbit.apache.org%3E] /cc [~cziegeler] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-5013) Introduce observation filter extension mechanism to Oak
[ https://issues.apache.org/jira/browse/OAK-5013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15611199#comment-15611199 ] Stefan Egli commented on OAK-5013: -- agreed, I'll adjust the wording accordingly. "write-through" was meant to be only between OakEventListener and the underlying, not that it modifies the filter after registration. > Introduce observation filter extension mechanism to Oak > --- > > Key: OAK-5013 > URL: https://issues.apache.org/jira/browse/OAK-5013 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: jcr >Affects Versions: 1.5.12 >Reporter: Stefan Egli >Assignee: Stefan Egli > Fix For: 1.5.13 > > Attachments: OAK-5013.patch > > > During [discussions|http://markmail.org/thread/fyngo4dwb7fvlqdj] regarding > extending JackrabbitEventFilter an interesting suggestion by [~mduerig] came > up that we could extend the JackrabbitEventFilter in oak explicitly, rather > than modifying it in Jackrabbit each time we add something oak-specific. > We should introduce a builder/interface pair in oak to reflect that. > Users that would like to use such oak-specific extensions would wrap a > JackrabbitEventFilter and get an OakEventFilter that contains enabling these > extensions. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-4911) Can not read node Property when move code into a Thread (Java)
[
https://issues.apache.org/jira/browse/OAK-4911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15611200#comment-15611200
]
amin zamani commented on OAK-4911:
--
Dear Support,
is there any new news knowledge about the error(s) / why it does not work?
Thanks and best regards,
Amin
> Can not read node Property when move code into a Thread (Java)
> --
>
> Key: OAK-4911
> URL: https://issues.apache.org/jira/browse/OAK-4911
> Project: Jackrabbit Oak
> Issue Type: Bug
>Affects Versions: 1.3.10
> Environment: MAC OS X
>Reporter: amin zamani
> Attachments: JCROakTest.java, java-code.txt, mixin-definitions.cnd
>
>
> Hallo,
> we develop an application and everything is working as it should. We upload
> documents and for each document a new preview file (node) should be
> generated. It works well when we execute the code synchron. But because of
> the fact that the generation of a preview file (like PDF format) can take
> very long time we decided to move the preview generation code into a usual
> java thread so that after the user is upload a document the website is
> responding very quick and does not wait till the preview file is generated
> but the preview file is generated parallel.
> No the problem: As soon as I move the same code regarding to the preview file
> generation into a usual thread (no modifications to the logic, only a thread
> is bordered to it) suddenly the node path does not exist, this is the error:
> -
> Caused by: javax.jcr.PathNotFoundException: jcr:lastModifiedBy not found on
> /jcr:system/jcr:versionStorage/7e/f8/5b/7ef85b25-4598-4476-82df-446eb3a08a90/1.0/jcr:frozenNode/jcr:content
> at
> org.apache.jackrabbit.oak.jcr.session.NodeImpl$11.perform(NodeImpl.java:631)
> at
> org.apache.jackrabbit.oak.jcr.session.NodeImpl$11.perform(NodeImpl.java:625)
> at
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.perform(SessionDelegate.java:207)
> at
> org.apache.jackrabbit.oak.jcr.session.ItemImpl.perform(ItemImpl.java:112)
> at
> org.apache.jackrabbit.oak.jcr.session.NodeImpl.getProperty(NodeImpl.java:625)
> at
> com.westernacher.noah.util.content_repository.JcrUtil.getStringProperty(JcrUtil.java:35)
> ---
> In my point of view this is a bug. This is the code that works:
> Example:
> /// 1) User Upload document through browser in our web app..
> // 2) ... document uploaded and saved in OAK CR
> // 3) Now generate the preview:
> updateDocumentPreview(documentId);
>
> Now the same in a thread that does not work:
> => I have only moved the method "updateDocumentPreview(documentId);" in a
> Thread (Java 8):
> //Same code as before except the last line replaced by following lines:
> Runnable run = ()-> {updateDocumentPreview(documentId);}
> new Thread(run).start(); //Start the thread to generate a document preview
> --
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-5018) Warn traversal queries: false positives
Thomas Mueller created OAK-5018:
---
Summary: Warn traversal queries: false positives
Key: OAK-5018
URL: https://issues.apache.org/jira/browse/OAK-5018
Project: Jackrabbit Oak
Issue Type: Bug
Reporter: Thomas Mueller
Assignee: Thomas Mueller
OAK-4888 logs a warning by default if there are queries that traverse. There
are false positives, for example if "ischildnode" is used:
{noformat}
/jcr:root/content/*/jcr:content[@xyz]
{noformat}
This needs to be fixed.
Temporarily, I will change the "warn" to "info" until this is resolved.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-5013) Introduce observation filter extension mechanism to Oak
[
https://issues.apache.org/jira/browse/OAK-5013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15611158#comment-15611158
]
Michael Dürig commented on OAK-5013:
+1 to this approach. One thing I'd like to clarify a bit more is the write
through behaviour. Even the {{JackrabbitEventFilter}} doesn't clearly say what
the effect of setting a property on the filter is. Does it modify a filter that
has already been passed to the observation manager? I guess not as "A storage
object for event filter configuration" seems to imply. But let's be extra clear
here.
> Introduce observation filter extension mechanism to Oak
> ---
>
> Key: OAK-5013
> URL: https://issues.apache.org/jira/browse/OAK-5013
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: jcr
>Affects Versions: 1.5.12
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: 1.5.13
>
> Attachments: OAK-5013.patch
>
>
> During [discussions|http://markmail.org/thread/fyngo4dwb7fvlqdj] regarding
> extending JackrabbitEventFilter an interesting suggestion by [~mduerig] came
> up that we could extend the JackrabbitEventFilter in oak explicitly, rather
> than modifying it in Jackrabbit each time we add something oak-specific.
> We should introduce a builder/interface pair in oak to reflect that.
> Users that would like to use such oak-specific extensions would wrap a
> JackrabbitEventFilter and get an OakEventFilter that contains enabling these
> extensions.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-5016) OOM in SegmentDataStoreBlobGCIT
[
https://issues.apache.org/jira/browse/OAK-5016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15611146#comment-15611146
]
Amit Jain commented on OAK-5016:
Done the following changes with -
http://svn.apache.org/viewvc?rev=1766781=rev
* Reduced the number of addition/deletions to 500/100 from 4000/500
* Added de-duplication cache size of 16384
Will keep this issue open to see if this resolves the issue.
> OOM in SegmentDataStoreBlobGCIT
> ---
>
> Key: OAK-5016
> URL: https://issues.apache.org/jira/browse/OAK-5016
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Reporter: Michael Dürig
> Labels: test-failure
> Fix For: 1.5.13
>
>
> I've seen that test going OOM on our Jenkins:
> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/1245/#showFailuresLink
> {noformat}
> java.lang.OutOfMemoryError: GC overhead limit exceeded
> at
> org.apache.jackrabbit.oak.segment.SegmentDataStoreBlobGCIT.setUp(SegmentDataStoreBlobGCIT.java:220)
> at
> org.apache.jackrabbit.oak.segment.SegmentDataStoreBlobGCIT.setUp(SegmentDataStoreBlobGCIT.java:141)
> at
> org.apache.jackrabbit.oak.segment.SegmentDataStoreBlobGCIT.consistencyCheckInit(SegmentDataStoreBlobGCIT.java:317)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (OAK-5016) OOM in SegmentDataStoreBlobGCIT
[
https://issues.apache.org/jira/browse/OAK-5016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amit Jain reassigned OAK-5016:
--
Assignee: Amit Jain
> OOM in SegmentDataStoreBlobGCIT
> ---
>
> Key: OAK-5016
> URL: https://issues.apache.org/jira/browse/OAK-5016
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Reporter: Michael Dürig
>Assignee: Amit Jain
> Labels: test-failure
> Fix For: 1.5.13
>
>
> I've seen that test going OOM on our Jenkins:
> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/1245/#showFailuresLink
> {noformat}
> java.lang.OutOfMemoryError: GC overhead limit exceeded
> at
> org.apache.jackrabbit.oak.segment.SegmentDataStoreBlobGCIT.setUp(SegmentDataStoreBlobGCIT.java:220)
> at
> org.apache.jackrabbit.oak.segment.SegmentDataStoreBlobGCIT.setUp(SegmentDataStoreBlobGCIT.java:141)
> at
> org.apache.jackrabbit.oak.segment.SegmentDataStoreBlobGCIT.consistencyCheckInit(SegmentDataStoreBlobGCIT.java:317)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-5016) OOM in SegmentDataStoreBlobGCIT
[
https://issues.apache.org/jira/browse/OAK-5016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15611098#comment-15611098
]
Michael Dürig commented on OAK-5016:
We can/should probably reduce the deduplication cache sizes for this test. Have
a look at the various {{FileStoreBuilder.withXXXDeduplicationCacheSize}}
methods. For the node deduplication cache 16384 might actually suffice here.
> OOM in SegmentDataStoreBlobGCIT
> ---
>
> Key: OAK-5016
> URL: https://issues.apache.org/jira/browse/OAK-5016
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Reporter: Michael Dürig
> Labels: test-failure
> Fix For: 1.5.13
>
>
> I've seen that test going OOM on our Jenkins:
> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/1245/#showFailuresLink
> {noformat}
> java.lang.OutOfMemoryError: GC overhead limit exceeded
> at
> org.apache.jackrabbit.oak.segment.SegmentDataStoreBlobGCIT.setUp(SegmentDataStoreBlobGCIT.java:220)
> at
> org.apache.jackrabbit.oak.segment.SegmentDataStoreBlobGCIT.setUp(SegmentDataStoreBlobGCIT.java:141)
> at
> org.apache.jackrabbit.oak.segment.SegmentDataStoreBlobGCIT.consistencyCheckInit(SegmentDataStoreBlobGCIT.java:317)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-5016) OOM in SegmentDataStoreBlobGCIT
[
https://issues.apache.org/jira/browse/OAK-5016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15611090#comment-15611090
]
Amit Jain commented on OAK-5016:
What I am trying is if we can do with less amount of garbage creation to make
compaction work. It was originally meant for oak-segment and may not be needed
here, which may help keep memory growth in check.
> OOM in SegmentDataStoreBlobGCIT
> ---
>
> Key: OAK-5016
> URL: https://issues.apache.org/jira/browse/OAK-5016
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Reporter: Michael Dürig
> Labels: test-failure
> Fix For: 1.5.13
>
>
> I've seen that test going OOM on our Jenkins:
> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/1245/#showFailuresLink
> {noformat}
> java.lang.OutOfMemoryError: GC overhead limit exceeded
> at
> org.apache.jackrabbit.oak.segment.SegmentDataStoreBlobGCIT.setUp(SegmentDataStoreBlobGCIT.java:220)
> at
> org.apache.jackrabbit.oak.segment.SegmentDataStoreBlobGCIT.setUp(SegmentDataStoreBlobGCIT.java:141)
> at
> org.apache.jackrabbit.oak.segment.SegmentDataStoreBlobGCIT.consistencyCheckInit(SegmentDataStoreBlobGCIT.java:317)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4857) Support space chars common in CJK inside node names
[
https://issues.apache.org/jira/browse/OAK-4857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15611055#comment-15611055
]
Marcel Reutegger commented on OAK-4857:
---
I'm also in favour of allowing those whitespace characters within a node name
and documenting it properly.
> Support space chars common in CJK inside node names
> ---
>
> Key: OAK-4857
> URL: https://issues.apache.org/jira/browse/OAK-4857
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.4.7, 1.5.10
>Reporter: Alexander Klimetschek
> Attachments: OAK-4857-tests.patch
>
>
> Oak (like Jackrabbit) does not allow spaces commonly used in CJK like
> {{u3000}} (ideographic space) or {{u00A0}} (no-break space) _inside_ a node
> name, while allowing some of them (the non breaking spaces) at the _beginning
> or end_.
> They should be supported for better globalization readiness, and filesystems
> allow them, making common filesystem to JCR mappings unnecessarily hard.
> Escaping would be an option for applications, but there is currently no
> utility method for it
> ([Text.escapeIllegalJcrChars|https://jackrabbit.apache.org/api/2.8/org/apache/jackrabbit/util/Text.html#escapeIllegalJcrChars(java.lang.String)]
> will not escape these spaces), nor is it documented for applications how to
> do so.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-5016) OOM in SegmentDataStoreBlobGCIT
[
https://issues.apache.org/jira/browse/OAK-5016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15611051#comment-15611051
]
Amit Jain commented on OAK-5016:
[~mduerig] Was looking at it...the line no. corresponds to
{code}
for (int k = 0; k < gcOptions.getRetainedGenerations(); k++) {
store.compact();
}
{code}
> OOM in SegmentDataStoreBlobGCIT
> ---
>
> Key: OAK-5016
> URL: https://issues.apache.org/jira/browse/OAK-5016
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Reporter: Michael Dürig
> Labels: test-failure
> Fix For: 1.5.13
>
>
> I've seen that test going OOM on our Jenkins:
> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/1245/#showFailuresLink
> {noformat}
> java.lang.OutOfMemoryError: GC overhead limit exceeded
> at
> org.apache.jackrabbit.oak.segment.SegmentDataStoreBlobGCIT.setUp(SegmentDataStoreBlobGCIT.java:220)
> at
> org.apache.jackrabbit.oak.segment.SegmentDataStoreBlobGCIT.setUp(SegmentDataStoreBlobGCIT.java:141)
> at
> org.apache.jackrabbit.oak.segment.SegmentDataStoreBlobGCIT.consistencyCheckInit(SegmentDataStoreBlobGCIT.java:317)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-5017) Standby test failures
Michael Dürig created OAK-5017:
--
Summary: Standby test failures
Key: OAK-5017
URL: https://issues.apache.org/jira/browse/OAK-5017
Project: Jackrabbit Oak
Issue Type: Bug
Components: segment-tar
Reporter: Michael Dürig
Fix For: 1.5.13
I've recently seen a couple of the standby tests fail. E.g. on Jenkins:
https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/1245/
{noformat}
java.lang.AssertionError: expected:
org.apache.jackrabbit.oak.segment.SegmentNodeState<{ checkpoints = { ... },
root = { ... } }> but was: org.apache.jackrabbit.oak.segment.SegmentNodeState<{
checkpoints = { ... }, root = { ... } }>
at
org.apache.jackrabbit.oak.segment.standby.StandbyTestIT.testSyncLoop(StandbyTestIT.java:122)
{noformat}
{noformat}
java.lang.AssertionError: expected:
org.apache.jackrabbit.oak.segment.SegmentNodeState<{ checkpoints = { ... },
root = { ... } }> but was: org.apache.jackrabbit.oak.segment.SegmentNodeState<{
checkpoints = { ... }, root = { ... } }>
at
org.apache.jackrabbit.oak.segment.standby.StandbyTestIT.testSyncLoop(StandbyTestIT.java:122)
{noformat}
{{org.apache.jackrabbit.oak.segment.standby.ExternalSharedStoreIT.testProxySkippedBytes}}:
{noformat}
java.lang.AssertionError: expected:<{ root = { ... } }> but was:<{ root : { } }>
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-5017) Standby test failures
[
https://issues.apache.org/jira/browse/OAK-5017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15611025#comment-15611025
]
Michael Dürig commented on OAK-5017:
[~marett], could you have a look?
> Standby test failures
> -
>
> Key: OAK-5017
> URL: https://issues.apache.org/jira/browse/OAK-5017
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Reporter: Michael Dürig
> Labels: test-failure
> Fix For: 1.5.13
>
>
> I've recently seen a couple of the standby tests fail. E.g. on Jenkins:
> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/1245/
> {noformat}
> java.lang.AssertionError: expected:
> org.apache.jackrabbit.oak.segment.SegmentNodeState<{ checkpoints = { ... },
> root = { ... } }> but was:
> org.apache.jackrabbit.oak.segment.SegmentNodeState<{ checkpoints = { ... },
> root = { ... } }>
> at
> org.apache.jackrabbit.oak.segment.standby.StandbyTestIT.testSyncLoop(StandbyTestIT.java:122)
> {noformat}
> {noformat}
> java.lang.AssertionError: expected:
> org.apache.jackrabbit.oak.segment.SegmentNodeState<{ checkpoints = { ... },
> root = { ... } }> but was:
> org.apache.jackrabbit.oak.segment.SegmentNodeState<{ checkpoints = { ... },
> root = { ... } }>
> at
> org.apache.jackrabbit.oak.segment.standby.StandbyTestIT.testSyncLoop(StandbyTestIT.java:122)
> {noformat}
> {{org.apache.jackrabbit.oak.segment.standby.ExternalSharedStoreIT.testProxySkippedBytes}}:
> {noformat}
> java.lang.AssertionError: expected:<{ root = { ... } }> but was:<{ root : { }
> }>
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-5016) OOM in SegmentDataStoreBlobGCIT
Michael Dürig created OAK-5016:
--
Summary: OOM in SegmentDataStoreBlobGCIT
Key: OAK-5016
URL: https://issues.apache.org/jira/browse/OAK-5016
Project: Jackrabbit Oak
Issue Type: Bug
Components: segment-tar
Reporter: Michael Dürig
Fix For: 1.5.13
I've seen that test going OOM on our Jenkins:
https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/1245/#showFailuresLink
{noformat}
java.lang.OutOfMemoryError: GC overhead limit exceeded
at
org.apache.jackrabbit.oak.segment.SegmentDataStoreBlobGCIT.setUp(SegmentDataStoreBlobGCIT.java:220)
at
org.apache.jackrabbit.oak.segment.SegmentDataStoreBlobGCIT.setUp(SegmentDataStoreBlobGCIT.java:141)
at
org.apache.jackrabbit.oak.segment.SegmentDataStoreBlobGCIT.consistencyCheckInit(SegmentDataStoreBlobGCIT.java:317)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-5016) OOM in SegmentDataStoreBlobGCIT
[
https://issues.apache.org/jira/browse/OAK-5016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15611005#comment-15611005
]
Michael Dürig commented on OAK-5016:
[~amitj_76], could you have a look?
> OOM in SegmentDataStoreBlobGCIT
> ---
>
> Key: OAK-5016
> URL: https://issues.apache.org/jira/browse/OAK-5016
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Reporter: Michael Dürig
> Labels: test-failure
> Fix For: 1.5.13
>
>
> I've seen that test going OOM on our Jenkins:
> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/1245/#showFailuresLink
> {noformat}
> java.lang.OutOfMemoryError: GC overhead limit exceeded
> at
> org.apache.jackrabbit.oak.segment.SegmentDataStoreBlobGCIT.setUp(SegmentDataStoreBlobGCIT.java:220)
> at
> org.apache.jackrabbit.oak.segment.SegmentDataStoreBlobGCIT.setUp(SegmentDataStoreBlobGCIT.java:141)
> at
> org.apache.jackrabbit.oak.segment.SegmentDataStoreBlobGCIT.consistencyCheckInit(SegmentDataStoreBlobGCIT.java:317)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-4314) BlobReferenceRetriever#collectReferences should allow exceptions
[
https://issues.apache.org/jira/browse/OAK-4314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig resolved OAK-4314.
Resolution: Fixed
Fix Version/s: (was: 1.6)
Fixed at http://svn.apache.org/viewvc?rev=1766772=rev
> BlobReferenceRetriever#collectReferences should allow exceptions
>
>
> Key: OAK-4314
> URL: https://issues.apache.org/jira/browse/OAK-4314
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, segment-tar
>Reporter: Michael Dürig
>Assignee: Michael Dürig
> Labels: datastore, gc, resilience
> Fix For: 1.5.13
>
>
> {{BlobReferenceRetriever#collectReferences}} currently does not allow
> implementations to throw an exception. In case anything goes wrong during
> reference collection, implementations should be able to indicate this through
> an exception so the DSGC can safely abort.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4966) Re-introduce a blocker for compaction based on available heap
[
https://issues.apache.org/jira/browse/OAK-4966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15610939#comment-15610939
]
Michael Dürig commented on OAK-4966:
Interesting. According to
https://docs.oracle.com/javase/7/docs/api/java/lang/management/MemoryPoolMXBean.html
we could use {{MEMORY_COLLECTION_THRESHOLD_EXCEEDED}} to get notified when
memory usage is above a certain threshold after a JVM gc.
> Re-introduce a blocker for compaction based on available heap
> -
>
> Key: OAK-4966
> URL: https://issues.apache.org/jira/browse/OAK-4966
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Reporter: Alex Parvulescu
>Assignee: Alex Parvulescu
> Fix For: 1.6, 1.5.13
>
> Attachments: OAK-4966.patch
>
>
> As seen in a local test, running compaction on a tight heap can lead to
> OOMEs. There used to be a best effort barrier against this situation 'not
> enough heap for compaction', but we removed it with the compaction maps.
> I think it makes sense to add it again based on the max size of some of the
> caches: segment cache {{256MB}} by default [0] and some writer caches which
> can go up to {{2GB}} all combined [1] and probably others I missed.
> [0]
> https://github.com/apache/jackrabbit-oak/blob/trunk/oak-segment-tar/src/main/java/org/apache/jackrabbit/oak/segment/SegmentCache.java#L48
> [1]
> https://github.com/apache/jackrabbit-oak/blob/trunk/oak-segment-tar/src/main/java/org/apache/jackrabbit/oak/segment/WriterCacheManager.java#L50
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4314) BlobReferenceRetriever#collectReferences should allow exceptions
[
https://issues.apache.org/jira/browse/OAK-4314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15610854#comment-15610854
]
Amit Jain commented on OAK-4314:
+1
> BlobReferenceRetriever#collectReferences should allow exceptions
>
>
> Key: OAK-4314
> URL: https://issues.apache.org/jira/browse/OAK-4314
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, segment-tar
>Reporter: Michael Dürig
>Assignee: Michael Dürig
> Labels: datastore, gc, resilience
> Fix For: 1.6, 1.5.13
>
>
> {{BlobReferenceRetriever#collectReferences}} currently does not allow
> implementations to throw an exception. In case anything goes wrong during
> reference collection, implementations should be able to indicate this through
> an exception so the DSGC can safely abort.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
