[jira] [Commented] (OAK-7998) [DirectBinaryAccess] Verify that binary exists in cloud before creating signed download URI
[ https://issues.apache.org/jira/browse/OAK-7998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16887507#comment-16887507 ] Matt Ryan commented on OAK-7998: This change includes a documentation update, and as such also requires that the website be deployed. > [DirectBinaryAccess] Verify that binary exists in cloud before creating > signed download URI > --- > > Key: OAK-7998 > URL: https://issues.apache.org/jira/browse/OAK-7998 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: blob-cloud, blob-cloud-azure >Affects Versions: 1.10.0 >Reporter: Matt Ryan >Assignee: Matt Ryan >Priority: Major > Fix For: 1.16.0, 1.10.4 > > > The direct binary access download logic doesn't actually verify that the > requested blob is available in the cloud before creating the signed download > URI. It is possible that a user could request a download URI for a blob that > is "in the repo" but hasn't actually been uploaded yet. > We should verify this by uploading a new blob, preventing it being uploaded > to the cloud (retain in cache), and then request the download URI. We should > get a null back or get some other error or exception; if we get a URI it > would return an HTTP 404 if the blob is not actually uploaded yet (maybe this > would also be ok). -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (OAK-8493) Build Jackrabbit Oak #2286 failed
Hudson created OAK-8493: --- Summary: Build Jackrabbit Oak #2286 failed Key: OAK-8493 URL: https://issues.apache.org/jira/browse/OAK-8493 Project: Jackrabbit Oak Issue Type: Bug Components: continuous integration Reporter: Hudson No description is provided The build Jackrabbit Oak #2286 has failed. First failed run: [Jackrabbit Oak #2286|https://builds.apache.org/job/Jackrabbit%20Oak/2286/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/2286/console] -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (OAK-7998) [DirectBinaryAccess] Verify that binary exists in cloud before creating signed download URI
[ https://issues.apache.org/jira/browse/OAK-7998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Ryan updated OAK-7998: --- Fix Version/s: 1.10.4 > [DirectBinaryAccess] Verify that binary exists in cloud before creating > signed download URI > --- > > Key: OAK-7998 > URL: https://issues.apache.org/jira/browse/OAK-7998 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: blob-cloud, blob-cloud-azure >Affects Versions: 1.10.0 >Reporter: Matt Ryan >Assignee: Matt Ryan >Priority: Major > Fix For: 1.16.0, 1.10.4 > > > The direct binary access download logic doesn't actually verify that the > requested blob is available in the cloud before creating the signed download > URI. It is possible that a user could request a download URI for a blob that > is "in the repo" but hasn't actually been uploaded yet. > We should verify this by uploading a new blob, preventing it being uploaded > to the cloud (retain in cache), and then request the download URI. We should > get a null back or get some other error or exception; if we get a URI it > would return an HTTP 404 if the blob is not actually uploaded yet (maybe this > would also be ok). -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (OAK-7998) [DirectBinaryAccess] Verify that binary exists in cloud before creating signed download URI
[ https://issues.apache.org/jira/browse/OAK-7998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16887500#comment-16887500 ] Matt Ryan commented on OAK-7998: Fixed in [r1863238|https://svn.apache.org/viewvc?view=revision=1863238]. > [DirectBinaryAccess] Verify that binary exists in cloud before creating > signed download URI > --- > > Key: OAK-7998 > URL: https://issues.apache.org/jira/browse/OAK-7998 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: blob-cloud, blob-cloud-azure >Affects Versions: 1.10.0 >Reporter: Matt Ryan >Assignee: Matt Ryan >Priority: Major > Fix For: 1.16.0 > > > The direct binary access download logic doesn't actually verify that the > requested blob is available in the cloud before creating the signed download > URI. It is possible that a user could request a download URI for a blob that > is "in the repo" but hasn't actually been uploaded yet. > We should verify this by uploading a new blob, preventing it being uploaded > to the cloud (retain in cache), and then request the download URI. We should > get a null back or get some other error or exception; if we get a URI it > would return an HTTP 404 if the blob is not actually uploaded yet (maybe this > would also be ok). -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (OAK-7998) [DirectBinaryAccess] Verify that binary exists in cloud before creating signed download URI
[ https://issues.apache.org/jira/browse/OAK-7998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Ryan updated OAK-7998: --- Description: The direct binary access download logic doesn't actually verify that the requested blob is available in the cloud before creating the signed download URI. It is possible that a user could request a download URI for a blob that is "in the repo" but hasn't actually been uploaded yet. We should verify this by uploading a new blob, preventing it being uploaded to the cloud (retain in cache), and then request the download URI. We should get a null back or get some other error or exception; if we get a URI it would return an HTTP 404 if the blob is not actually uploaded yet (maybe this would also be ok). was: IIUC, the direct binary access download logic doesn't actually verify that the requested blob is available in the cloud before creating the signed download URI. It is possible that a user could request a download URI for a blob that is "in the repo" but hasn't actually been uploaded yet. We should verify this by uploading a new blob, preventing it being uploaded to the cloud (retain in cache), and then request the download URI. We should get a null back or get some other error or exception; if we get a URI it would return an HTTP 404 if the blob is not actually uploaded yet (maybe this would also be ok). > [DirectBinaryAccess] Verify that binary exists in cloud before creating > signed download URI > --- > > Key: OAK-7998 > URL: https://issues.apache.org/jira/browse/OAK-7998 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: blob-cloud, blob-cloud-azure >Affects Versions: 1.10.0 >Reporter: Matt Ryan >Assignee: Matt Ryan >Priority: Major > Fix For: 1.16.0 > > > The direct binary access download logic doesn't actually verify that the > requested blob is available in the cloud before creating the signed download > URI. It is possible that a user could request a download URI for a blob that > is "in the repo" but hasn't actually been uploaded yet. > We should verify this by uploading a new blob, preventing it being uploaded > to the cloud (retain in cache), and then request the download URI. We should > get a null back or get some other error or exception; if we get a URI it > would return an HTTP 404 if the blob is not actually uploaded yet (maybe this > would also be ok). -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (OAK-8484) Build Jackrabbit Oak #2283 failed
[ https://issues.apache.org/jira/browse/OAK-8484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16887314#comment-16887314 ] Hudson commented on OAK-8484: - Previously failing build now is OK. Passed run: [Jackrabbit Oak #2285|https://builds.apache.org/job/Jackrabbit%20Oak/2285/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/2285/console] > Build Jackrabbit Oak #2283 failed > - > > Key: OAK-8484 > URL: https://issues.apache.org/jira/browse/OAK-8484 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > No description is provided > The build Jackrabbit Oak #2283 has failed. > First failed run: [Jackrabbit Oak > #2283|https://builds.apache.org/job/Jackrabbit%20Oak/2283/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/2283/console] -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Resolved] (OAK-8492) PrincipalAccessControlList: misleading notnull annotation with effective path param
[ https://issues.apache.org/jira/browse/OAK-8492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela resolved OAK-8492. - Resolution: Fixed Committed revision 1863225. > PrincipalAccessControlList: misleading notnull annotation with effective path > param > --- > > Key: OAK-8492 > URL: https://issues.apache.org/jira/browse/OAK-8492 > Project: Jackrabbit Oak > Issue Type: Bug > Components: jackrabbit-api >Reporter: angela >Assignee: angela >Priority: Minor > Fix For: 1.16.0 > > > just noticed that in contrast to the javadoc and the implementation that > clearly allows the effective path to be null for repository level, the > interface annotates the param to be notnull. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (OAK-8492) PrincipalAccessControlList: misleading notnull annotation with effective path param
angela created OAK-8492: --- Summary: PrincipalAccessControlList: misleading notnull annotation with effective path param Key: OAK-8492 URL: https://issues.apache.org/jira/browse/OAK-8492 Project: Jackrabbit Oak Issue Type: Bug Components: jackrabbit-api Reporter: angela Assignee: angela Fix For: 1.16.0 just noticed that in contrast to the javadoc and the implementation that clearly allows the effective path to be null for repository level, the interface annotates the param to be notnull. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (OAK-8482) Remove false positives of SNFE on azure execution time out
[ https://issues.apache.org/jira/browse/OAK-8482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16887153#comment-16887153 ] Andrei Dulceanu commented on OAK-8482: -- [~frm], sure I'll commit it. Thanks for reviewing! > Remove false positives of SNFE on azure execution time out > -- > > Key: OAK-8482 > URL: https://issues.apache.org/jira/browse/OAK-8482 > Project: Jackrabbit Oak > Issue Type: Bug > Components: segment-azure, segment-tar >Reporter: Ieran Draghiciu >Assignee: Andrei Dulceanu >Priority: Major > Attachments: OAK-8482-03.patch, OAK-8482-04.patch, > OAK-SNFE-false-positives-02.diff > > > When reading a Tar file goes in execution time out a SNFE is thrown and the > SNFE metric is't increased. > We need to not increase the metric and add extra logging to SNFE. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (OAK-8482) Remove false positives of SNFE on azure execution time out
[ https://issues.apache.org/jira/browse/OAK-8482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16887151#comment-16887151 ] Francesco Mari commented on OAK-8482: - [~ierandra], [~dulceanu], the patch looks good to me. [~dulceanu], will you take care of the commit? > Remove false positives of SNFE on azure execution time out > -- > > Key: OAK-8482 > URL: https://issues.apache.org/jira/browse/OAK-8482 > Project: Jackrabbit Oak > Issue Type: Bug > Components: segment-azure, segment-tar >Reporter: Ieran Draghiciu >Assignee: Andrei Dulceanu >Priority: Major > Attachments: OAK-8482-03.patch, OAK-8482-04.patch, > OAK-SNFE-false-positives-02.diff > > > When reading a Tar file goes in execution time out a SNFE is thrown and the > SNFE metric is't increased. > We need to not increase the metric and add extra logging to SNFE. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (OAK-8482) Remove false positives of SNFE on azure execution time out
[
https://issues.apache.org/jira/browse/OAK-8482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16887148#comment-16887148
]
Andrei Dulceanu commented on OAK-8482:
--
[~frm], thanks for reviewing! I followed your simplified approach in the new
patch, but treated a bit differently the {{RepositoryNotReachableException}} in
the {{FileStore}}, i.e. didn't wrap it in a {{SegmentNotFoundException}}, since
this is not the case anyways. I also came up with two new tests for reading
segments. Could you please take a look?
> Remove false positives of SNFE on azure execution time out
> --
>
> Key: OAK-8482
> URL: https://issues.apache.org/jira/browse/OAK-8482
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-azure, segment-tar
>Reporter: Ieran Draghiciu
>Assignee: Andrei Dulceanu
>Priority: Major
> Attachments: OAK-8482-03.patch, OAK-8482-04.patch,
> OAK-SNFE-false-positives-02.diff
>
>
> When reading a Tar file goes in execution time out a SNFE is thrown and the
> SNFE metric is't increased.
> We need to not increase the metric and add extra logging to SNFE.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (OAK-8482) Remove false positives of SNFE on azure execution time out
[ https://issues.apache.org/jira/browse/OAK-8482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16887131#comment-16887131 ] Ieran Draghiciu commented on OAK-8482: -- Thanks [~dulceanu] for the test. [~frm] what do you think? It's safe to commit? I also tested manually by deleting segments from azure and the SNFE was generated. When we had the timeout from Azure a RepositoryNotReachableException was thrown. > Remove false positives of SNFE on azure execution time out > -- > > Key: OAK-8482 > URL: https://issues.apache.org/jira/browse/OAK-8482 > Project: Jackrabbit Oak > Issue Type: Bug > Components: segment-azure, segment-tar >Reporter: Ieran Draghiciu >Assignee: Andrei Dulceanu >Priority: Major > Attachments: OAK-8482-03.patch, OAK-8482-04.patch, > OAK-SNFE-false-positives-02.diff > > > When reading a Tar file goes in execution time out a SNFE is thrown and the > SNFE metric is't increased. > We need to not increase the metric and add extra logging to SNFE. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (OAK-8491) Review default size of eagerCache parameter
angela created OAK-8491: --- Summary: Review default size of eagerCache parameter Key: OAK-8491 URL: https://issues.apache.org/jira/browse/OAK-8491 Project: Jackrabbit Oak Issue Type: Improvement Components: core, security Reporter: angela Assignee: angela [~stillalex], based on the benchmarks in OAK-8227, i would like to suggest that we review the default size of the _eagerCache_ with the default authorization model. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (OAK-8482) Remove false positives of SNFE on azure execution time out
[ https://issues.apache.org/jira/browse/OAK-8482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulceanu updated OAK-8482: - Attachment: OAK-8482-04.patch > Remove false positives of SNFE on azure execution time out > -- > > Key: OAK-8482 > URL: https://issues.apache.org/jira/browse/OAK-8482 > Project: Jackrabbit Oak > Issue Type: Bug > Components: segment-azure, segment-tar >Reporter: Ieran Draghiciu >Assignee: Andrei Dulceanu >Priority: Major > Attachments: OAK-8482-03.patch, OAK-8482-04.patch, > OAK-SNFE-false-positives-02.diff > > > When reading a Tar file goes in execution time out a SNFE is thrown and the > SNFE metric is't increased. > We need to not increase the metric and add extra logging to SNFE. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (OAK-5887) Stricter validation on primary type change
[
https://issues.apache.org/jira/browse/OAK-5887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16886974#comment-16886974
]
Julian Reschke commented on OAK-5887:
-
[~stillalex] - do we need this in the next release?
> Stricter validation on primary type change
> --
>
> Key: OAK-5887
> URL: https://issues.apache.org/jira/browse/OAK-5887
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, jcr
>Reporter: Alex Deparvu
>Assignee: Alex Deparvu
>Priority: Major
> Labels: candidate_oak_1_6
> Fix For: 1.7.0, 1.8.0
>
>
> This issue tracks the {{oak-core}} changes on the {{TypeEditor}} to have
> better protection against corruption when changing a node's primary type.
> Basically first 2 items on [~mreutegg]'s summarization of OAK-5229 [0].
> [0]
> https://issues.apache.org/jira/browse/OAK-5229?focusedCommentId=15863871=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15863871
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (OAK-4529) DocumentNodeStore does not have a repository software version range check
[ https://issues.apache.org/jira/browse/OAK-4529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16886972#comment-16886972 ] Julian Reschke commented on OAK-4529: - [~mreutegg] - do we need this in the next release? > DocumentNodeStore does not have a repository software version range check > - > > Key: OAK-4529 > URL: https://issues.apache.org/jira/browse/OAK-4529 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core, documentmk >Affects Versions: 1.0.31, 1.2.14, 1.4.4, 1.5.4 >Reporter: Ian Boston >Assignee: Marcel Reutegger >Priority: Major > Labels: candidate_oak_1_6 > Fix For: 1.7.0, 1.8.0 > > Attachments: OAK-4529.patch > > > DocumentNodeStore does not currently check which software version the > persisted repository it is connecting to was created with or last updated. > There is a risk that if the versions are incompatible the repository may be > damaged. > Somewhere in the repository, the version of the software that created it, and > the versions that written to it should be stored. In the case of TarMK this > information could be on local disk near the TarMK files. In the case of a > DocumentMK implementation, the information should be stored in the "database" > itself. > When a DocumentNodeStore instance connects it should: check the versions > stored in the repository then check the versions are within a compatible > range and refuse to start if not. > When a DocumentNodeStore writes to a repository, it should add its version to > the list of versions that have updated the repository. > This check behaviour should be active in full Oak or any utilities (eg > oak-run). -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (OAK-7956) Conflict may leave behind _collisions entry
[
https://issues.apache.org/jira/browse/OAK-7956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16886971#comment-16886971
]
Julian Reschke commented on OAK-7956:
-
[~mreutegg] - do we need this in the next release?
> Conflict may leave behind _collisions entry
> ---
>
> Key: OAK-7956
> URL: https://issues.apache.org/jira/browse/OAK-7956
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: documentmk
>Affects Versions: 1.4.0, 1.6.0, 1.8.0
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
>Priority: Major
> Labels: candidate_oak_1_4, candidate_oak_1_6
> Fix For: 1.10.0, 1.8.14
>
>
> Under high concurrent conflicting workload, entries in the {{_collisions}}
> map may be left behind and accumulate over time.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (OAK-8482) Remove false positives of SNFE on azure execution time out
[ https://issues.apache.org/jira/browse/OAK-8482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulceanu updated OAK-8482: - Affects Version/s: 1.14.0 > Remove false positives of SNFE on azure execution time out > -- > > Key: OAK-8482 > URL: https://issues.apache.org/jira/browse/OAK-8482 > Project: Jackrabbit Oak > Issue Type: Bug > Components: segment-azure, segment-tar >Affects Versions: 1.14.0 >Reporter: Ieran Draghiciu >Assignee: Andrei Dulceanu >Priority: Major > Attachments: OAK-8482-03.patch, OAK-SNFE-false-positives-02.diff > > > When reading a Tar file goes in execution time out a SNFE is thrown and the > SNFE metric is't increased. > We need to not increase the metric and add extra logging to SNFE. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (OAK-8482) Remove false positives of SNFE on azure execution time out
[ https://issues.apache.org/jira/browse/OAK-8482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulceanu updated OAK-8482: - Affects Version/s: (was: 1.16.0) > Remove false positives of SNFE on azure execution time out > -- > > Key: OAK-8482 > URL: https://issues.apache.org/jira/browse/OAK-8482 > Project: Jackrabbit Oak > Issue Type: Bug > Components: segment-azure, segment-tar >Reporter: Ieran Draghiciu >Assignee: Andrei Dulceanu >Priority: Major > Attachments: OAK-8482-03.patch, OAK-SNFE-false-positives-02.diff > > > When reading a Tar file goes in execution time out a SNFE is thrown and the > SNFE metric is't increased. > We need to not increase the metric and add extra logging to SNFE. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (OAK-8482) Remove false positives of SNFE on azure execution time out
[ https://issues.apache.org/jira/browse/OAK-8482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulceanu updated OAK-8482: - Affects Version/s: (was: 1.14.0) 1.16.0 > Remove false positives of SNFE on azure execution time out > -- > > Key: OAK-8482 > URL: https://issues.apache.org/jira/browse/OAK-8482 > Project: Jackrabbit Oak > Issue Type: Bug > Components: segment-azure, segment-tar >Affects Versions: 1.16.0 >Reporter: Ieran Draghiciu >Assignee: Andrei Dulceanu >Priority: Major > Attachments: OAK-8482-03.patch, OAK-SNFE-false-positives-02.diff > > > When reading a Tar file goes in execution time out a SNFE is thrown and the > SNFE metric is't increased. > We need to not increase the metric and add extra logging to SNFE. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (OAK-8482) Remove false positives of SNFE on azure execution time out
[ https://issues.apache.org/jira/browse/OAK-8482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulceanu updated OAK-8482: - Component/s: segment-tar > Remove false positives of SNFE on azure execution time out > -- > > Key: OAK-8482 > URL: https://issues.apache.org/jira/browse/OAK-8482 > Project: Jackrabbit Oak > Issue Type: Bug > Components: segment-tar >Reporter: Ieran Draghiciu >Assignee: Andrei Dulceanu >Priority: Major > Attachments: OAK-8482-03.patch, OAK-SNFE-false-positives-02.diff > > > When reading a Tar file goes in execution time out a SNFE is thrown and the > SNFE metric is't increased. > We need to not increase the metric and add extra logging to SNFE. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (OAK-8482) Remove false positives of SNFE on azure execution time out
[ https://issues.apache.org/jira/browse/OAK-8482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulceanu updated OAK-8482: - Component/s: segment-azure > Remove false positives of SNFE on azure execution time out > -- > > Key: OAK-8482 > URL: https://issues.apache.org/jira/browse/OAK-8482 > Project: Jackrabbit Oak > Issue Type: Bug > Components: segment-azure, segment-tar >Reporter: Ieran Draghiciu >Assignee: Andrei Dulceanu >Priority: Major > Attachments: OAK-8482-03.patch, OAK-SNFE-false-positives-02.diff > > > When reading a Tar file goes in execution time out a SNFE is thrown and the > SNFE metric is't increased. > We need to not increase the metric and add extra logging to SNFE. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (OAK-8490) FilterProviderImpl.getFilter may fail if principal cache enabled
[
https://issues.apache.org/jira/browse/OAK-8490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated OAK-8490:
Attachment: (was: OAK-8490.patch)
> FilterProviderImpl.getFilter may fail if principal cache enabled
>
>
> Key: OAK-8490
> URL: https://issues.apache.org/jira/browse/OAK-8490
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: authorization-principalbased, core
>Reporter: angela
>Assignee: angela
>Priority: Major
> Fix For: 1.16.0
>
> Attachments: OAK-8490-2.patch
>
>
> in case principal caching is enabled (see {{UserPrincipalProvider}}), calling
> {{FilterProviderImpl.getFilter}} with a readonly {{Root}} will fail because
> it fails to obtain the contentsession/authInfo from the {{ImmutableRoot}}
> object.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (OAK-8490) FilterProviderImpl.getFilter may fail if principal cache enabled
[
https://issues.apache.org/jira/browse/OAK-8490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated OAK-8490:
Attachment: OAK-8490-2.patch
> FilterProviderImpl.getFilter may fail if principal cache enabled
>
>
> Key: OAK-8490
> URL: https://issues.apache.org/jira/browse/OAK-8490
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: authorization-principalbased, core
>Reporter: angela
>Assignee: angela
>Priority: Major
> Fix For: 1.16.0
>
> Attachments: OAK-8490-2.patch
>
>
> in case principal caching is enabled (see {{UserPrincipalProvider}}), calling
> {{FilterProviderImpl.getFilter}} with a readonly {{Root}} will fail because
> it fails to obtain the contentsession/authInfo from the {{ImmutableRoot}}
> object.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (OAK-8466) Old inactive clusterIds may trigger expensive recovery
[ https://issues.apache.org/jira/browse/OAK-8466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16886775#comment-16886775 ] Vinod Holani commented on OAK-8466: --- Hi [~mreutegg] please review the attached patch. > Old inactive clusterIds may trigger expensive recovery > -- > > Key: OAK-8466 > URL: https://issues.apache.org/jira/browse/OAK-8466 > Project: Jackrabbit Oak > Issue Type: Bug > Components: documentmk >Reporter: Vinod Holani >Priority: Major > Attachments: OAK-8466.patch > > > If a clusterId becomes active that has been inactive for a long time and > crashes without ever updating the _lastRev on the root document, then a > _lastRev recovery that kicks in will be expensive. The recovery process will > go through all documents that have been modified while the clusterId was > inactive. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (OAK-8466) Old inactive clusterIds may trigger expensive recovery
[ https://issues.apache.org/jira/browse/OAK-8466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vinod Holani updated OAK-8466: -- Attachment: OAK-8466.patch > Old inactive clusterIds may trigger expensive recovery > -- > > Key: OAK-8466 > URL: https://issues.apache.org/jira/browse/OAK-8466 > Project: Jackrabbit Oak > Issue Type: Bug > Components: documentmk >Reporter: Vinod Holani >Priority: Major > Attachments: OAK-8466.patch > > > If a clusterId becomes active that has been inactive for a long time and > crashes without ever updating the _lastRev on the root document, then a > _lastRev recovery that kicks in will be expensive. The recovery process will > go through all documents that have been modified while the clusterId was > inactive. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (OAK-8490) FilterProviderImpl.getFilter may fail if principal cache enabled
[
https://issues.apache.org/jira/browse/OAK-8490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16886772#comment-16886772
]
angela commented on OAK-8490:
-
[~stillalex], proposed patch for {{ImmutableRoot}} attached including test
cases illustrating the issue. unless you have concerns regarding the proposed
changes, i would commit it along with extra unit tests for {{ImmutableRoot}}.
> FilterProviderImpl.getFilter may fail if principal cache enabled
>
>
> Key: OAK-8490
> URL: https://issues.apache.org/jira/browse/OAK-8490
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: authorization-principalbased, core
>Reporter: angela
>Assignee: angela
>Priority: Major
> Fix For: 1.16.0
>
> Attachments: OAK-8490.patch
>
>
> in case principal caching is enabled (see {{UserPrincipalProvider}}), calling
> {{FilterProviderImpl.getFilter}} with a readonly {{Root}} will fail because
> it fails to obtain the contentsession/authInfo from the {{ImmutableRoot}}
> object.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (OAK-8490) FilterProviderImpl.getFilter may fail if principal cache enabled
[
https://issues.apache.org/jira/browse/OAK-8490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated OAK-8490:
Attachment: OAK-8490.patch
> FilterProviderImpl.getFilter may fail if principal cache enabled
>
>
> Key: OAK-8490
> URL: https://issues.apache.org/jira/browse/OAK-8490
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: authorization-principalbased, core
>Reporter: angela
>Assignee: angela
>Priority: Major
> Fix For: 1.16.0
>
> Attachments: OAK-8490.patch
>
>
> in case principal caching is enabled (see {{UserPrincipalProvider}}), calling
> {{FilterProviderImpl.getFilter}} with a readonly {{Root}} will fail because
> it fails to obtain the contentsession/authInfo from the {{ImmutableRoot}}
> object.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (OAK-8490) FilterProviderImpl.getFilter may fail if principal cache enabled
[
https://issues.apache.org/jira/browse/OAK-8490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated OAK-8490:
Component/s: core
> FilterProviderImpl.getFilter may fail if principal cache enabled
>
>
> Key: OAK-8490
> URL: https://issues.apache.org/jira/browse/OAK-8490
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: authorization-principalbased, core
>Reporter: angela
>Assignee: angela
>Priority: Major
> Fix For: 1.16.0
>
>
> in case principal caching is enabled (see {{UserPrincipalProvider}}), calling
> {{FilterProviderImpl.getFilter}} with a readonly {{Root}} will fail because
> it fails to obtain the contentsession/authInfo from the {{ImmutableRoot}}
> object.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Created] (OAK-8490) FilterProviderImpl.getFilter may fail if principal cache enabled
angela created OAK-8490:
---
Summary: FilterProviderImpl.getFilter may fail if principal cache
enabled
Key: OAK-8490
URL: https://issues.apache.org/jira/browse/OAK-8490
Project: Jackrabbit Oak
Issue Type: Bug
Components: authorization-principalbased
Reporter: angela
Assignee: angela
Fix For: 1.16.0
in case principal caching is enabled (see {{UserPrincipalProvider}}), calling
{{FilterProviderImpl.getFilter}} with a readonly {{Root}} will fail because it
fails to obtain the contentsession/authInfo from the {{ImmutableRoot}} object.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
