[jira] [Commented] (OAK-7467) Build Jackrabbit Oak #1419 failed
[ https://issues.apache.org/jira/browse/OAK-7467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16461344#comment-16461344 ] Hudson commented on OAK-7467: - Previously failing build now is OK. Passed run: [Jackrabbit Oak #1422|https://builds.apache.org/job/Jackrabbit%20Oak/1422/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/1422/console] > Build Jackrabbit Oak #1419 failed > - > > Key: OAK-7467 > URL: https://issues.apache.org/jira/browse/OAK-7467 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > No description is provided > The build Jackrabbit Oak #1419 has failed. > First failed run: [Jackrabbit Oak > #1419|https://builds.apache.org/job/Jackrabbit%20Oak/1419/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/1419/console] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-7468) RootProvider and TreeProvider should be marked as provider type
[
https://issues.apache.org/jira/browse/OAK-7468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16461233#comment-16461233
]
Alex Deparvu commented on OAK-7468:
---
+1
> RootProvider and TreeProvider should be marked as provider type
> ---
>
> Key: OAK-7468
> URL: https://issues.apache.org/jira/browse/OAK-7468
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: security-spi
>Reporter: angela
>Assignee: angela
>Priority: Minor
>
> for the sake of consistency i think {{RootProvider}} and {{TreeProvider}}
> should be marked as provider type.
> [~stillalex] fyi
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-7469) User membership synchronization could skip updating groups the user is already part of
[ https://issues.apache.org/jira/browse/OAK-7469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Deparvu updated OAK-7469: -- Summary: User membership synchronization could skip updating groups the user is already part of (was: User Group membership synchronization could skip groups the user is already part of ) > User membership synchronization could skip updating groups the user is > already part of > --- > > Key: OAK-7469 > URL: https://issues.apache.org/jira/browse/OAK-7469 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: auth-external, security >Reporter: Alex Deparvu >Assignee: Alex Deparvu >Priority: Major > Fix For: 1.10 > > Attachments: OAK-7469.patch > > > Currently the user group membership sync process doesn't take into account > what groups the user is already a part of, so it will update all groups > information by adding the user. we can skip this step based on group > information on the user. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-7469) User membership synchronization could skip updating groups the user is already part of
[ https://issues.apache.org/jira/browse/OAK-7469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Deparvu updated OAK-7469: -- Fix Version/s: 1.10 > User membership synchronization could skip updating groups the user is > already part of > --- > > Key: OAK-7469 > URL: https://issues.apache.org/jira/browse/OAK-7469 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: auth-external, security >Reporter: Alex Deparvu >Assignee: Alex Deparvu >Priority: Major > Fix For: 1.10 > > Attachments: OAK-7469.patch > > > Currently the user group membership sync process doesn't take into account > what groups the user is already a part of, so it will update all groups > information by adding the user. we can skip this step based on group > information on the user. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-7469) User Group membership synchronization could skip groups the user is already part of
[ https://issues.apache.org/jira/browse/OAK-7469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16461229#comment-16461229 ] Alex Deparvu commented on OAK-7469: --- [~anchela] thoughts? > User Group membership synchronization could skip groups the user is already > part of > > > Key: OAK-7469 > URL: https://issues.apache.org/jira/browse/OAK-7469 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: auth-external, security >Reporter: Alex Deparvu >Assignee: Alex Deparvu >Priority: Major > Attachments: OAK-7469.patch > > > Currently the user group membership sync process doesn't take into account > what groups the user is already a part of, so it will update all groups > information by adding the user. we can skip this step based on group > information on the user. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-7469) User Group membership synchronization could skip groups the user is already part of
[
https://issues.apache.org/jira/browse/OAK-7469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16461228#comment-16461228
]
Alex Deparvu commented on OAK-7469:
---
attaching proposed patch: [^OAK-7469.patch]. benchmarks show a dramatic
improvement for the worst case (all group info needs to be synced), which is
maybe not the case at all times (unless the group sync is forced). this also
doesn't apply if dynamic group membership is enabled.
*Benchmarks*:
* trunk
{noformat}
# SyncAllExternalUsersTest C min 10% 50% 90% max
N
Oak-MemoryNS 1 110600 110600 110600 110600 110600
1
Oak-Segment-Tar1 167825 167825 167825 167825 167825
1
# SyncAllUsersTest C min 10% 50% 90% max
N
Oak-MemoryNS 1 104743 104743 104743 104743 104743
1
Oak-Segment-Tar1 208043 208043 208043 208043 208043
1
# SyncExternalUsersTestC min 10% 50% 90% max
N
Oak-MemoryNS 1 2 4 17 27 40
3708
Oak-Segment-Tar1 3 7 21 37 65
2784
{noformat}
* patch
{noformat}
# SyncAllExternalUsersTest C min 10% 50% 90% max
N
Oak-MemoryNS 1 13394 13394 13692 14906 14906
5
Oak-Segment-Tar1 28995 28995 29693 29766 29766
3
# SyncAllUsersTest C min 10% 50% 90% max
N
Oak-MemoryNS 1 14680 14680 15505 16937 16937
4
Oak-Segment-Tar1 30496 30496 30853 31210 31210
2
# SyncExternalUsersTestC min 10% 50% 90% max
N
Oak-MemoryNS 1 1 4 18 29 52
3565
Oak-Segment-Tar1 2 5 21 37 70
2801
{noformat}
{{SyncAllExternalUsersTest}} is _down to 13%_ of the trunk version,
{{SyncAllUsersTest}} _down to 16%_, weirdly enough {{SyncExternalUsersTest}}
goes up a bit so I might have to dig into it a bit more, if needed.
> User Group membership synchronization could skip groups the user is already
> part of
>
>
> Key: OAK-7469
> URL: https://issues.apache.org/jira/browse/OAK-7469
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: auth-external, security
>Reporter: Alex Deparvu
>Assignee: Alex Deparvu
>Priority: Major
> Attachments: OAK-7469.patch
>
>
> Currently the user group membership sync process doesn't take into account
> what groups the user is already a part of, so it will update all groups
> information by adding the user. we can skip this step based on group
> information on the user.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-7469) User Group membership synchronization could skip groups the user is already part of
[ https://issues.apache.org/jira/browse/OAK-7469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Deparvu updated OAK-7469: -- Attachment: OAK-7469.patch > User Group membership synchronization could skip groups the user is already > part of > > > Key: OAK-7469 > URL: https://issues.apache.org/jira/browse/OAK-7469 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: auth-external, security >Reporter: Alex Deparvu >Assignee: Alex Deparvu >Priority: Major > Attachments: OAK-7469.patch > > > Currently the user group membership sync process doesn't take into account > what groups the user is already a part of, so it will update all groups > information by adding the user. we can skip this step based on group > information on the user. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (OAK-7469) User Group membership synchronization could skip groups the user is already part of
Alex Deparvu created OAK-7469: - Summary: User Group membership synchronization could skip groups the user is already part of Key: OAK-7469 URL: https://issues.apache.org/jira/browse/OAK-7469 Project: Jackrabbit Oak Issue Type: Improvement Components: auth-external, security Reporter: Alex Deparvu Assignee: Alex Deparvu Currently the user group membership sync process doesn't take into account what groups the user is already a part of, so it will update all groups information by adding the user. we can skip this step based on group information on the user. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-7467) Build Jackrabbit Oak #1419 failed
[ https://issues.apache.org/jira/browse/OAK-7467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16461147#comment-16461147 ] Hudson commented on OAK-7467: - Previously failing build now is OK. Passed run: [Jackrabbit Oak #1421|https://builds.apache.org/job/Jackrabbit%20Oak/1421/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/1421/console] > Build Jackrabbit Oak #1419 failed > - > > Key: OAK-7467 > URL: https://issues.apache.org/jira/browse/OAK-7467 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > No description is provided > The build Jackrabbit Oak #1419 has failed. > First failed run: [Jackrabbit Oak > #1419|https://builds.apache.org/job/Jackrabbit%20Oak/1419/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/1419/console] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (OAK-7468) RootProvider and TreeProvider should be marked as provider type
angela created OAK-7468:
---
Summary: RootProvider and TreeProvider should be marked as
provider type
Key: OAK-7468
URL: https://issues.apache.org/jira/browse/OAK-7468
Project: Jackrabbit Oak
Issue Type: Improvement
Components: security-spi
Reporter: angela
Assignee: angela
for the sake of consistency i think {{RootProvider}} and {{TreeProvider}}
should be marked as provider type.
[~stillalex] fyi
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (OAK-7466) Prevent LMSEstimator over/under flow in weights
[ https://issues.apache.org/jira/browse/OAK-7466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili resolved OAK-7466. -- Resolution: Fixed Fix Version/s: 1.6.12 1.8.3 > Prevent LMSEstimator over/under flow in weights > --- > > Key: OAK-7466 > URL: https://issues.apache.org/jira/browse/OAK-7466 > Project: Jackrabbit Oak > Issue Type: Bug > Components: solr >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili >Priority: Major > Fix For: 1.8.3, 1.6.12, 1.9.1 > > > Although I could not reproduce it with a unit test, it is theoretically > possible to have weights be updated to _Infinite_ or _NaN_ due to double > multiplication over / underflow. > A simple check should be introduced in the case of estimates not being finite > to reset weights. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-7467) Build Jackrabbit Oak #1419 failed
[ https://issues.apache.org/jira/browse/OAK-7467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16461025#comment-16461025 ] Hudson commented on OAK-7467: - Build is still failing. Failed run: [Jackrabbit Oak #1420|https://builds.apache.org/job/Jackrabbit%20Oak/1420/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/1420/console] > Build Jackrabbit Oak #1419 failed > - > > Key: OAK-7467 > URL: https://issues.apache.org/jira/browse/OAK-7467 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > No description is provided > The build Jackrabbit Oak #1419 has failed. > First failed run: [Jackrabbit Oak > #1419|https://builds.apache.org/job/Jackrabbit%20Oak/1419/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/1419/console] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-2931) RDBDocumentStore: mitigate effects of large query result sets
[ https://issues.apache.org/jira/browse/OAK-2931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-2931: Description: With the DocumentStore query API, large result sets can happen; and these are returned as List, potentially causing large amounts of memory to be allocated. In the current implementation, the result list is generated based on a list of internal row presentations (RDBRow). These are currently freed when the method finishes. They should be freed as early as possible. Furthermore, when the result set gets big, RDBDocumentStore should log an error containing the call chain, so that the component doing the excessive query can be identified (it should use paging instead). (For completeness: we could also change the code to lazily populate the list; but that would be a bigger change) was: With the DocumentStore query API, large result sets can happen; and these are returned as List, potentially causing large amounts of memory to be allocated. In the current implementation, the result list is generated based on a list of internal row presentations (RDBRow). These are currently freed when the method finishes. They should be freed as early as possible. Furthermore, when the result set gets big, RDBDocumentStore should llog an error containing the call chain, so that the component doing the excessive query can be identified (it should use paging instead). (For completeness: we could also change the code to lazily populate the list; but that would be a bigger change) > RDBDocumentStore: mitigate effects of large query result sets > - > > Key: OAK-2931 > URL: https://issues.apache.org/jira/browse/OAK-2931 > Project: Jackrabbit Oak > Issue Type: Sub-task > Components: rdbmk >Affects Versions: 1.0.14, 1.2.2 >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Major > Labels: resilience > Fix For: 1.0.15, 1.2.3, 1.3.0, 1.4 > > > With the DocumentStore query API, large result sets can happen; and these are > returned as List, potentially causing large amounts of memory to be > allocated. > In the current implementation, the result list is generated based on a list > of internal row presentations (RDBRow). These are currently freed when the > method finishes. They should be freed as early as possible. > Furthermore, when the result set gets big, RDBDocumentStore should log an > error containing the call chain, so that the component doing the excessive > query can be identified (it should use paging instead). > (For completeness: we could also change the code to lazily populate the list; > but that would be a bigger change) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (OAK-7467) Build Jackrabbit Oak #1419 failed
Hudson created OAK-7467: --- Summary: Build Jackrabbit Oak #1419 failed Key: OAK-7467 URL: https://issues.apache.org/jira/browse/OAK-7467 Project: Jackrabbit Oak Issue Type: Bug Components: continuous integration Reporter: Hudson No description is provided The build Jackrabbit Oak #1419 has failed. First failed run: [Jackrabbit Oak #1419|https://builds.apache.org/job/Jackrabbit%20Oak/1419/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/1419/console] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (OAK-7464) Allow to choose which instance should initialize the default mount
[ https://issues.apache.org/jira/browse/OAK-7464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16460822#comment-16460822 ] Tomek Rękawek edited comment on OAK-7464 at 5/2/18 10:46 AM: - Fixed for trunk in [r1830739|https://svn.apache.org/r1830739], [r1830742|https://svn.apache.org/r1830742]. was (Author: tomek.rekawek): Fixed for trunk in [r1830739|https://svn.apache.org/r1830739]. > Allow to choose which instance should initialize the default mount > -- > > Key: OAK-7464 > URL: https://issues.apache.org/jira/browse/OAK-7464 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: composite >Reporter: Tomek Rękawek >Priority: Major > Fix For: 1.10, 1.9.1 > > > When the InitialContentMigrator is run in a cluster environment, it could be > useful to specify which instance (referenced by cluster id) should initialize > the repository. Other instances should wait. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-7465) It should be possible for an Azure Segment Store to wait until the lease if released
[ https://issues.apache.org/jira/browse/OAK-7465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16460823#comment-16460823 ] Tomek Rękawek commented on OAK-7465: Fixed for trunk [r1830740|https://svn.apache.org/r1830740]. > It should be possible for an Azure Segment Store to wait until the lease if > released > > > Key: OAK-7465 > URL: https://issues.apache.org/jira/browse/OAK-7465 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: segment-tar >Reporter: Tomek Rękawek >Priority: Major > Fix For: 1.10, 1.9.1 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (OAK-7465) It should be possible for an Azure Segment Store to wait until the lease if released
[ https://issues.apache.org/jira/browse/OAK-7465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomek Rękawek resolved OAK-7465. Resolution: Fixed > It should be possible for an Azure Segment Store to wait until the lease if > released > > > Key: OAK-7465 > URL: https://issues.apache.org/jira/browse/OAK-7465 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: segment-tar >Reporter: Tomek Rękawek >Priority: Major > Fix For: 1.10, 1.9.1 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-7464) Allow to choose which instance should initialize the default mount
[ https://issues.apache.org/jira/browse/OAK-7464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16460822#comment-16460822 ] Tomek Rękawek commented on OAK-7464: Fixed for trunk in [r1830739|https://svn.apache.org/r1830739]. > Allow to choose which instance should initialize the default mount > -- > > Key: OAK-7464 > URL: https://issues.apache.org/jira/browse/OAK-7464 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: composite >Reporter: Tomek Rękawek >Priority: Major > Fix For: 1.10, 1.9.1 > > > When the InitialContentMigrator is run in a cluster environment, it could be > useful to specify which instance (referenced by cluster id) should initialize > the repository. Other instances should wait. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (OAK-7464) Allow to choose which instance should initialize the default mount
[ https://issues.apache.org/jira/browse/OAK-7464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomek Rękawek resolved OAK-7464. Resolution: Fixed > Allow to choose which instance should initialize the default mount > -- > > Key: OAK-7464 > URL: https://issues.apache.org/jira/browse/OAK-7464 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: composite >Reporter: Tomek Rękawek >Priority: Major > Fix For: 1.10, 1.9.1 > > > When the InitialContentMigrator is run in a cluster environment, it could be > useful to specify which instance (referenced by cluster id) should initialize > the repository. Other instances should wait. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (OAK-7466) Prevent LMSEstimator over/under flow in weights
Tommaso Teofili created OAK-7466: Summary: Prevent LMSEstimator over/under flow in weights Key: OAK-7466 URL: https://issues.apache.org/jira/browse/OAK-7466 Project: Jackrabbit Oak Issue Type: Bug Components: solr Reporter: Tommaso Teofili Assignee: Tommaso Teofili Fix For: 1.9.1 Although I could not reproduce it with a unit test, it is theoretically possible to have weights be updated to _Infinite_ or _NaN_ due to double multiplication over / underflow. A simple check should be introduced in the case of estimates not being finite to reset weights. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (OAK-7465) It should be possible for an Azure Segment Store to wait until the lease if released
Tomek Rękawek created OAK-7465: -- Summary: It should be possible for an Azure Segment Store to wait until the lease if released Key: OAK-7465 URL: https://issues.apache.org/jira/browse/OAK-7465 Project: Jackrabbit Oak Issue Type: Improvement Components: segment-tar Reporter: Tomek Rękawek Fix For: 1.10, 1.9.1 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (OAK-7409) Move Lucene agnostic utilities out of oak-lucene into oak-search
[ https://issues.apache.org/jira/browse/OAK-7409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili resolved OAK-7409. -- Resolution: Fixed > Move Lucene agnostic utilities out of oak-lucene into oak-search > > > Key: OAK-7409 > URL: https://issues.apache.org/jira/browse/OAK-7409 > Project: Jackrabbit Oak > Issue Type: Technical task >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili >Priority: Major > Fix For: 1.9.1 > > > The _oak-lucene_ module contains abstractions and utilities that are Lucene > agnostic and that would be useful in the new _oak-search_ module to be > possibly reused by _oak-search_ implementors. > One example is the aggregation code, but also the stored index tracking code > and base test classes might be useful for other indexers. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-7343) Improvements to PermissionEntryProviderImpl
[
https://issues.apache.org/jira/browse/OAK-7343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated OAK-7343:
Attachment: OAK-7424.patch
OAK-7424-tests.patch
> Improvements to PermissionEntryProviderImpl
> ---
>
> Key: OAK-7343
> URL: https://issues.apache.org/jira/browse/OAK-7343
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, security
>Reporter: angela
>Assignee: angela
>Priority: Major
> Labels: performance
> Attachments: OAK-7424-tests.patch, OAK-7424.patch
>
>
> Container issue to track potential improvements to
> {{PermissionEntryProviderImpl}} based on discussions with [~stillalex].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-7343) Improvements to PermissionEntryProviderImpl
[
https://issues.apache.org/jira/browse/OAK-7343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16460769#comment-16460769
]
angela commented on OAK-7343:
-
[~stillalex], applied changes against latest trunk again -> svn patch attached.
> Improvements to PermissionEntryProviderImpl
> ---
>
> Key: OAK-7343
> URL: https://issues.apache.org/jira/browse/OAK-7343
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, security
>Reporter: angela
>Assignee: angela
>Priority: Major
> Labels: performance
> Attachments: OAK-7424-tests.patch, OAK-7424.patch
>
>
> Container issue to track potential improvements to
> {{PermissionEntryProviderImpl}} based on discussions with [~stillalex].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (OAK-7464) Allow to choose which instance should initialize the default mount
Tomek Rękawek created OAK-7464: -- Summary: Allow to choose which instance should initialize the default mount Key: OAK-7464 URL: https://issues.apache.org/jira/browse/OAK-7464 Project: Jackrabbit Oak Issue Type: Improvement Components: composite Reporter: Tomek Rękawek Fix For: 1.10, 1.9.1 When the InitialContentMigrator is run in a cluster environment, it could be useful to specify which instance (referenced by cluster id) should initialize the repository. Other instances should wait. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-7461) Build Jackrabbit Oak #1417 failed
[ https://issues.apache.org/jira/browse/OAK-7461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16460719#comment-16460719 ] Hudson commented on OAK-7461: - Previously failing build now is OK. Passed run: [Jackrabbit Oak #1418|https://builds.apache.org/job/Jackrabbit%20Oak/1418/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/1418/console] > Build Jackrabbit Oak #1417 failed > - > > Key: OAK-7461 > URL: https://issues.apache.org/jira/browse/OAK-7461 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > No description is provided > The build Jackrabbit Oak #1417 has failed. > First failed run: [Jackrabbit Oak > #1417|https://builds.apache.org/job/Jackrabbit%20Oak/1417/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/1417/console] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (OAK-7463) Update Tika to 1.18
[ https://issues.apache.org/jira/browse/OAK-7463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Deparvu resolved OAK-7463. --- Resolution: Duplicate Fix Version/s: (was: 1.10) pff, [~julian.resc...@gmx.de] beat me to it! > Update Tika to 1.18 > --- > > Key: OAK-7463 > URL: https://issues.apache.org/jira/browse/OAK-7463 > Project: Jackrabbit Oak > Issue Type: Task > Components: lucene >Reporter: Alex Deparvu >Priority: Major > > Due to Tika Vulnerabilities (CVE-2018-1338, CVE-2018-1339), we have to > upgrade to 1.18. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-7463) Update Tika to 1.18
[ https://issues.apache.org/jira/browse/OAK-7463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Deparvu updated OAK-7463: -- Fix Version/s: 1.10 > Update Tika to 1.18 > --- > > Key: OAK-7463 > URL: https://issues.apache.org/jira/browse/OAK-7463 > Project: Jackrabbit Oak > Issue Type: Task > Components: lucene >Reporter: Alex Deparvu >Priority: Major > Fix For: 1.10 > > > Due to Tika Vulnerabilities (CVE-2018-1338, CVE-2018-1339), we have to > upgrade to 1.18. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (OAK-7463) Update Tika to 1.18
Alex Deparvu created OAK-7463: - Summary: Update Tika to 1.18 Key: OAK-7463 URL: https://issues.apache.org/jira/browse/OAK-7463 Project: Jackrabbit Oak Issue Type: Task Components: lucene Reporter: Alex Deparvu Due to Tika Vulnerabilities (CVE-2018-1338, CVE-2018-1339), we have to upgrade to 1.18. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (OAK-7462) Benchmark for SynchronizationMBean#syncAllUsers
[
https://issues.apache.org/jira/browse/OAK-7462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Deparvu resolved OAK-7462.
---
Resolution: Fixed
Fix Version/s: 1.9.1
1.10
http://svn.apache.org/viewvc?rev=1830727&view=rev
> Benchmark for SynchronizationMBean#syncAllUsers
> ---
>
> Key: OAK-7462
> URL: https://issues.apache.org/jira/browse/OAK-7462
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: auth-external, security
>Reporter: Alex Deparvu
>Assignee: Alex Deparvu
>Priority: Minor
> Fix For: 1.10, 1.9.1
>
>
> New benchmark for the {{SynchronizationMBean#syncAllUsers}} method.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (OAK-7462) Benchmark for SynchronizationMBean#syncAllUsers
Alex Deparvu created OAK-7462:
-
Summary: Benchmark for SynchronizationMBean#syncAllUsers
Key: OAK-7462
URL: https://issues.apache.org/jira/browse/OAK-7462
Project: Jackrabbit Oak
Issue Type: Task
Components: auth-external, security
Reporter: Alex Deparvu
Assignee: Alex Deparvu
New benchmark for the {{SynchronizationMBean#syncAllUsers}} method.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
