[jira] [Created] (OAK-9334) Build Jackrabbit/jackrabbit-oak-trunk #135 failed

[Hudson (Jira)]

Hudson created OAK-9334:
---

 Summary: Build Jackrabbit/jackrabbit-oak-trunk #135 failed
 Key: OAK-9334
 URL: https://issues.apache.org/jira/browse/OAK-9334
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: continuous integration
Reporter: Hudson


No description is provided

The build Jackrabbit/jackrabbit-oak-trunk #135 has failed.
First failed run: [Jackrabbit/jackrabbit-oak-trunk 
#135|https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-oak-trunk/135/] 
[console 
log|https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-oak-trunk/135/console]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (OAK-9330) Build Jackrabbit/jackrabbit-oak-trunk #131 failed

[Hudson (Jira)]

[ 
https://issues.apache.org/jira/browse/OAK-9330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17269512#comment-17269512
 ] 

Hudson commented on OAK-9330:
-

Previously failing build now is OK.
 Passed run: [Jackrabbit/jackrabbit-oak-trunk 
#134|https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-oak-trunk/134/] 
[console 
log|https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-oak-trunk/134/console]

> Build Jackrabbit/jackrabbit-oak-trunk #131 failed
> -
>
> Key: OAK-9330
> URL: https://issues.apache.org/jira/browse/OAK-9330
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: continuous integration
>Reporter: Hudson
>Priority: Major
>
> No description is provided
> The build Jackrabbit/jackrabbit-oak-trunk #131 has failed.
> First failed run: [Jackrabbit/jackrabbit-oak-trunk 
> #131|https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-oak-trunk/131/]
>  [console 
> log|https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-oak-trunk/131/console]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (OAK-9333) Javadoc for PrincipalProvider.getPrincipalProvider is outdated

[Angela Schreiber (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-9333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Angela Schreiber resolved OAK-9333.
---
Fix Version/s: 1.38.0
   Resolution: Fixed

Committed revision 1885766.


> Javadoc for PrincipalProvider.getPrincipalProvider is outdated
> --
>
> Key: OAK-9333
> URL: https://issues.apache.org/jira/browse/OAK-9333
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: security-spi
>Reporter: Angela Schreiber
>Assignee: Angela Schreiber
>Priority: Minor
> Fix For: 1.38.0
>
>
> javadoc for {{PrincipalProvider.getPrincipalProvider}} is outdated and 
> doesn't properly reflect how multiple providers can be combined in jackrabbit 
> oak.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (OAK-9333) Javadoc for PrincipalProvider.getPrincipalProvider is outdated

[Angela Schreiber (Jira)]

Angela Schreiber created OAK-9333:
-

 Summary: Javadoc for PrincipalProvider.getPrincipalProvider is 
outdated
 Key: OAK-9333
 URL: https://issues.apache.org/jira/browse/OAK-9333
 Project: Jackrabbit Oak
  Issue Type: Improvement
  Components: security-spi
Reporter: Angela Schreiber


javadoc for {{PrincipalProvider.getPrincipalProvider}} is outdated and doesn't 
properly reflect how multiple providers can be combined in jackrabbit oak.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Assigned] (OAK-9333) Javadoc for PrincipalProvider.getPrincipalProvider is outdated

[Angela Schreiber (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-9333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Angela Schreiber reassigned OAK-9333:
-

Assignee: Angela Schreiber

> Javadoc for PrincipalProvider.getPrincipalProvider is outdated
> --
>
> Key: OAK-9333
> URL: https://issues.apache.org/jira/browse/OAK-9333
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: security-spi
>Reporter: Angela Schreiber
>Assignee: Angela Schreiber
>Priority: Minor
>
> javadoc for {{PrincipalProvider.getPrincipalProvider}} is outdated and 
> doesn't properly reflect how multiple providers can be combined in jackrabbit 
> oak.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (OAK-9324) oak-auth-ldap (UseUidForExtIdTest) tests fail (likely specific to Windows)

[Angela Schreiber (Jira)]

[ 
https://issues.apache.org/jira/browse/OAK-9324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17269465#comment-17269465
 ] 

Angela Schreiber commented on OAK-9324:
---

[~mreutegg], oh i just was about to commit the exact same fix after typing 
a lengthy comment (see above) and got:
{code}
Transmitting file data .svn: E155011: Commit failed (details follow):
svn: E155011: File 
'/Users/angela/Dev/oak_trunk/oak-auth-ldap/src/test/java/org/apache/jackrabbit/oak/security/authentication/ldap/impl/PoolableUnboundConnectionFactoryTest.java'
 is out of date
{code}
but thanks for sort of 'reviewing' my analysis and fix ;)

> oak-auth-ldap (UseUidForExtIdTest) tests fail (likely specific to Windows)
> --
>
> Key: OAK-9324
> URL: https://issues.apache.org/jira/browse/OAK-9324
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: auth-ldap
>Reporter: Julian Reschke
>Assignee: Marcel Reutegger
>Priority: Minor
> Fix For: 1.38.0
>
>
> {noformat}
> [INFO] Running 
> org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest
> [ERROR] Tests run: 18, Failures: 0, Errors: 18, Skipped: 0, Time elapsed: 
> 0.184 s <<< FAILURE! - in org.apache.jackrabbit.oak.security.auth
> entication.ldap.impl.UseUidForExtIdTest
> [ERROR] 
> testAuthenticate(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.029 s  <<< ERROR!
> java.lang.reflect.InvocationTargetException
> Caused by: java.io.IOException: Unable to delete file: 
> target\apacheds\cache\c68efd7d-7963-4972-b27c-c2ace6c83b63\ou=system.data
> [ERROR] 
> testAuthenticate(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.029 s  <<< ERROR!
> java.lang.NullPointerException
> [ERROR] 
> testGetGroupByRef(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.021 s  <<< ERROR
> !
> java.lang.reflect.InvocationTargetException
> Caused by: java.io.IOException: Unable to delete file: 
> target\apacheds\cache\c68efd7d-7963-4972-b27c-c2ace6c83b63\ou=system.data
> [ERROR] 
> testGetGroupByRef(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.021 s  <<< ERROR
> !
> java.lang.NullPointerException
> [ERROR] 
> testGetUnknownUserByRef(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.019 s  <<<
>  ERROR!
> java.lang.reflect.InvocationTargetException
> Caused by: java.io.IOException: Unable to delete file: 
> target\apacheds\cache\c68efd7d-7963-4972-b27c-c2ace6c83b63\ou=system.data
> [ERROR] 
> testGetUnknownUserByRef(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.019 s  <<<
>  ERROR!
> java.lang.NullPointerException
> [ERROR] 
> testGetGroups2(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.019 s  <<< ERROR!
> java.lang.reflect.InvocationTargetException
> Caused by: java.io.IOException: Unable to delete file: 
> target\apacheds\cache\c68efd7d-7963-4972-b27c-c2ace6c83b63\ou=system.data
> [ERROR] 
> testGetGroups2(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.019 s  <<< ERROR!
> java.lang.NullPointerException
> [ERROR] 
> testAuthenticateCaseInsensitive(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.02
>  s  <<< ERROR!
> java.lang.reflect.InvocationTargetException
> Caused by: java.io.IOException: Unable to delete file: 
> target\apacheds\cache\c68efd7d-7963-4972-b27c-c2ace6c83b63\ou=system.data
> [ERROR] 
> testAuthenticateCaseInsensitive(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.02
>  s  <<< ERROR!
> java.lang.NullPointerException
> [ERROR] 
> testGetGroups(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.018 s  <<< ERROR!
> java.lang.reflect.InvocationTargetException
> Caused by: java.io.IOException: Unable to delete file: 
> target\apacheds\cache\c68efd7d-7963-4972-b27c-c2ace6c83b63\ou=system.data
> [ERROR] 
> testGetGroups(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.018 s  <<< ERROR!
> java.lang.NullPointerException
> [ERROR] 
> testGetMembers(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.019 s  <<< ERROR!
> java.lang.reflect.InvocationTargetException
> Caused by: java.io.IOException: Unable to delete file: 
> target\apacheds\cache\c68efd7d-7963-4972-b27c-c2ace6c83b63\ou=system.data
> [ERROR] 
> 

[jira] [Resolved] (OAK-9324) oak-auth-ldap (UseUidForExtIdTest) tests fail (likely specific to Windows)

[Marcel Reutegger (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-9324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Reutegger resolved OAK-9324.
---
Fix Version/s: (was: 1.40.0)
   1.38.0
   Resolution: Fixed

Fixed in trunk: http://svn.apache.org/r1885765

> oak-auth-ldap (UseUidForExtIdTest) tests fail (likely specific to Windows)
> --
>
> Key: OAK-9324
> URL: https://issues.apache.org/jira/browse/OAK-9324
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: auth-ldap
>Reporter: Julian Reschke
>Assignee: Marcel Reutegger
>Priority: Minor
> Fix For: 1.38.0
>
>
> {noformat}
> [INFO] Running 
> org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest
> [ERROR] Tests run: 18, Failures: 0, Errors: 18, Skipped: 0, Time elapsed: 
> 0.184 s <<< FAILURE! - in org.apache.jackrabbit.oak.security.auth
> entication.ldap.impl.UseUidForExtIdTest
> [ERROR] 
> testAuthenticate(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.029 s  <<< ERROR!
> java.lang.reflect.InvocationTargetException
> Caused by: java.io.IOException: Unable to delete file: 
> target\apacheds\cache\c68efd7d-7963-4972-b27c-c2ace6c83b63\ou=system.data
> [ERROR] 
> testAuthenticate(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.029 s  <<< ERROR!
> java.lang.NullPointerException
> [ERROR] 
> testGetGroupByRef(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.021 s  <<< ERROR
> !
> java.lang.reflect.InvocationTargetException
> Caused by: java.io.IOException: Unable to delete file: 
> target\apacheds\cache\c68efd7d-7963-4972-b27c-c2ace6c83b63\ou=system.data
> [ERROR] 
> testGetGroupByRef(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.021 s  <<< ERROR
> !
> java.lang.NullPointerException
> [ERROR] 
> testGetUnknownUserByRef(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.019 s  <<<
>  ERROR!
> java.lang.reflect.InvocationTargetException
> Caused by: java.io.IOException: Unable to delete file: 
> target\apacheds\cache\c68efd7d-7963-4972-b27c-c2ace6c83b63\ou=system.data
> [ERROR] 
> testGetUnknownUserByRef(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.019 s  <<<
>  ERROR!
> java.lang.NullPointerException
> [ERROR] 
> testGetGroups2(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.019 s  <<< ERROR!
> java.lang.reflect.InvocationTargetException
> Caused by: java.io.IOException: Unable to delete file: 
> target\apacheds\cache\c68efd7d-7963-4972-b27c-c2ace6c83b63\ou=system.data
> [ERROR] 
> testGetGroups2(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.019 s  <<< ERROR!
> java.lang.NullPointerException
> [ERROR] 
> testAuthenticateCaseInsensitive(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.02
>  s  <<< ERROR!
> java.lang.reflect.InvocationTargetException
> Caused by: java.io.IOException: Unable to delete file: 
> target\apacheds\cache\c68efd7d-7963-4972-b27c-c2ace6c83b63\ou=system.data
> [ERROR] 
> testAuthenticateCaseInsensitive(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.02
>  s  <<< ERROR!
> java.lang.NullPointerException
> [ERROR] 
> testGetGroups(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.018 s  <<< ERROR!
> java.lang.reflect.InvocationTargetException
> Caused by: java.io.IOException: Unable to delete file: 
> target\apacheds\cache\c68efd7d-7963-4972-b27c-c2ace6c83b63\ou=system.data
> [ERROR] 
> testGetGroups(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.018 s  <<< ERROR!
> java.lang.NullPointerException
> [ERROR] 
> testGetMembers(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.019 s  <<< ERROR!
> java.lang.reflect.InvocationTargetException
> Caused by: java.io.IOException: Unable to delete file: 
> target\apacheds\cache\c68efd7d-7963-4972-b27c-c2ace6c83b63\ou=system.data
> [ERROR] 
> testGetMembers(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.019 s  <<< ERROR!
> java.lang.NullPointerException
> [ERROR] 
> testGetUserByRef(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.019 s  <<< ERROR!
> java.lang.reflect.InvocationTargetException
> Caused by: java.io.IOException: Unable to delete file: 
> 

[jira] [Commented] (OAK-9324) oak-auth-ldap (UseUidForExtIdTest) tests fail (likely specific to Windows)

[Angela Schreiber (Jira)]

[ 
https://issues.apache.org/jira/browse/OAK-9324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17269459#comment-17269459
 ] 

Angela Schreiber commented on OAK-9324:
---

[~reschke], as i mentioned on the mailing list, i am not able to reproduce the 
failures (have not windows machine). as far as i can see the tests failing on 
your machine have in common that they make use of the {{LdapServerClassLoader}} 
introduced with OAK-8769 (commit with additional comment stating {quote}The 
LDAP test server now uses a separate ClassLoader because it still uses 
v1{quote}).

a second observation:
at the very end of the description i found that not only modified/new tests 
failed but also existing unmodified tests like {{LdapDefaultLoginModuleTest}}, 
{{TokenDefaultLdapLoginModuleTest}} and {{LargeLdapProviderTest}}.
would you be able to run these tests individually to check if they fail?
and what about {{UseUidForExtIdTest}}? does it fail when being executed 
individually?

a third observation:
the test {{PoolableUnboundConnectionFactoryTest}}: the class was modified to 
also have a {{LdapServerClassLoader.Proxy}} setup in {{beforeClass()}}... but 
it lacks {{proxy.tearDown()}} once tests are completed. i will add that and 
would ask you to check if that would solve the issue.

cc: [~adulceanu]






> oak-auth-ldap (UseUidForExtIdTest) tests fail (likely specific to Windows)
> --
>
> Key: OAK-9324
> URL: https://issues.apache.org/jira/browse/OAK-9324
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: auth-ldap
>Reporter: Julian Reschke
>Assignee: Marcel Reutegger
>Priority: Minor
> Fix For: 1.38.0
>
>
> {noformat}
> [INFO] Running 
> org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest
> [ERROR] Tests run: 18, Failures: 0, Errors: 18, Skipped: 0, Time elapsed: 
> 0.184 s <<< FAILURE! - in org.apache.jackrabbit.oak.security.auth
> entication.ldap.impl.UseUidForExtIdTest
> [ERROR] 
> testAuthenticate(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.029 s  <<< ERROR!
> java.lang.reflect.InvocationTargetException
> Caused by: java.io.IOException: Unable to delete file: 
> target\apacheds\cache\c68efd7d-7963-4972-b27c-c2ace6c83b63\ou=system.data
> [ERROR] 
> testAuthenticate(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.029 s  <<< ERROR!
> java.lang.NullPointerException
> [ERROR] 
> testGetGroupByRef(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.021 s  <<< ERROR
> !
> java.lang.reflect.InvocationTargetException
> Caused by: java.io.IOException: Unable to delete file: 
> target\apacheds\cache\c68efd7d-7963-4972-b27c-c2ace6c83b63\ou=system.data
> [ERROR] 
> testGetGroupByRef(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.021 s  <<< ERROR
> !
> java.lang.NullPointerException
> [ERROR] 
> testGetUnknownUserByRef(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.019 s  <<<
>  ERROR!
> java.lang.reflect.InvocationTargetException
> Caused by: java.io.IOException: Unable to delete file: 
> target\apacheds\cache\c68efd7d-7963-4972-b27c-c2ace6c83b63\ou=system.data
> [ERROR] 
> testGetUnknownUserByRef(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.019 s  <<<
>  ERROR!
> java.lang.NullPointerException
> [ERROR] 
> testGetGroups2(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.019 s  <<< ERROR!
> java.lang.reflect.InvocationTargetException
> Caused by: java.io.IOException: Unable to delete file: 
> target\apacheds\cache\c68efd7d-7963-4972-b27c-c2ace6c83b63\ou=system.data
> [ERROR] 
> testGetGroups2(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.019 s  <<< ERROR!
> java.lang.NullPointerException
> [ERROR] 
> testAuthenticateCaseInsensitive(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.02
>  s  <<< ERROR!
> java.lang.reflect.InvocationTargetException
> Caused by: java.io.IOException: Unable to delete file: 
> target\apacheds\cache\c68efd7d-7963-4972-b27c-c2ace6c83b63\ou=system.data
> [ERROR] 
> testAuthenticateCaseInsensitive(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.02
>  s  <<< ERROR!
> java.lang.NullPointerException
> [ERROR] 
> testGetGroups(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.018 s  <<< ERROR!
> java.lang.reflect.InvocationTargetException
> Caused by: 

[jira] [Assigned] (OAK-9324) oak-auth-ldap (UseUidForExtIdTest) tests fail (likely specific to Windows)

[Marcel Reutegger (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-9324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Reutegger reassigned OAK-9324:
-

Assignee: Marcel Reutegger

> oak-auth-ldap (UseUidForExtIdTest) tests fail (likely specific to Windows)
> --
>
> Key: OAK-9324
> URL: https://issues.apache.org/jira/browse/OAK-9324
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: auth-ldap
>Reporter: Julian Reschke
>Assignee: Marcel Reutegger
>Priority: Minor
> Fix For: 1.40.0
>
>
> {noformat}
> [INFO] Running 
> org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest
> [ERROR] Tests run: 18, Failures: 0, Errors: 18, Skipped: 0, Time elapsed: 
> 0.184 s <<< FAILURE! - in org.apache.jackrabbit.oak.security.auth
> entication.ldap.impl.UseUidForExtIdTest
> [ERROR] 
> testAuthenticate(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.029 s  <<< ERROR!
> java.lang.reflect.InvocationTargetException
> Caused by: java.io.IOException: Unable to delete file: 
> target\apacheds\cache\c68efd7d-7963-4972-b27c-c2ace6c83b63\ou=system.data
> [ERROR] 
> testAuthenticate(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.029 s  <<< ERROR!
> java.lang.NullPointerException
> [ERROR] 
> testGetGroupByRef(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.021 s  <<< ERROR
> !
> java.lang.reflect.InvocationTargetException
> Caused by: java.io.IOException: Unable to delete file: 
> target\apacheds\cache\c68efd7d-7963-4972-b27c-c2ace6c83b63\ou=system.data
> [ERROR] 
> testGetGroupByRef(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.021 s  <<< ERROR
> !
> java.lang.NullPointerException
> [ERROR] 
> testGetUnknownUserByRef(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.019 s  <<<
>  ERROR!
> java.lang.reflect.InvocationTargetException
> Caused by: java.io.IOException: Unable to delete file: 
> target\apacheds\cache\c68efd7d-7963-4972-b27c-c2ace6c83b63\ou=system.data
> [ERROR] 
> testGetUnknownUserByRef(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.019 s  <<<
>  ERROR!
> java.lang.NullPointerException
> [ERROR] 
> testGetGroups2(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.019 s  <<< ERROR!
> java.lang.reflect.InvocationTargetException
> Caused by: java.io.IOException: Unable to delete file: 
> target\apacheds\cache\c68efd7d-7963-4972-b27c-c2ace6c83b63\ou=system.data
> [ERROR] 
> testGetGroups2(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.019 s  <<< ERROR!
> java.lang.NullPointerException
> [ERROR] 
> testAuthenticateCaseInsensitive(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.02
>  s  <<< ERROR!
> java.lang.reflect.InvocationTargetException
> Caused by: java.io.IOException: Unable to delete file: 
> target\apacheds\cache\c68efd7d-7963-4972-b27c-c2ace6c83b63\ou=system.data
> [ERROR] 
> testAuthenticateCaseInsensitive(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.02
>  s  <<< ERROR!
> java.lang.NullPointerException
> [ERROR] 
> testGetGroups(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.018 s  <<< ERROR!
> java.lang.reflect.InvocationTargetException
> Caused by: java.io.IOException: Unable to delete file: 
> target\apacheds\cache\c68efd7d-7963-4972-b27c-c2ace6c83b63\ou=system.data
> [ERROR] 
> testGetGroups(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.018 s  <<< ERROR!
> java.lang.NullPointerException
> [ERROR] 
> testGetMembers(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.019 s  <<< ERROR!
> java.lang.reflect.InvocationTargetException
> Caused by: java.io.IOException: Unable to delete file: 
> target\apacheds\cache\c68efd7d-7963-4972-b27c-c2ace6c83b63\ou=system.data
> [ERROR] 
> testGetMembers(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.019 s  <<< ERROR!
> java.lang.NullPointerException
> [ERROR] 
> testGetUserByRef(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.019 s  <<< ERROR!
> java.lang.reflect.InvocationTargetException
> Caused by: java.io.IOException: Unable to delete file: 
> target\apacheds\cache\c68efd7d-7963-4972-b27c-c2ace6c83b63\ou=system.data
> [ERROR] 
> 

[jira] [Updated] (OAK-9324) oak-auth-ldap (UseUidForExtIdTest) tests fail (likely specific to Windows)

[Angela Schreiber (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-9324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Angela Schreiber updated OAK-9324:
--
Priority: Minor  (was: Major)

> oak-auth-ldap (UseUidForExtIdTest) tests fail (likely specific to Windows)
> --
>
> Key: OAK-9324
> URL: https://issues.apache.org/jira/browse/OAK-9324
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: auth-ldap
>Reporter: Julian Reschke
>Priority: Minor
> Fix For: 1.40.0
>
>
> {noformat}
> [INFO] Running 
> org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest
> [ERROR] Tests run: 18, Failures: 0, Errors: 18, Skipped: 0, Time elapsed: 
> 0.184 s <<< FAILURE! - in org.apache.jackrabbit.oak.security.auth
> entication.ldap.impl.UseUidForExtIdTest
> [ERROR] 
> testAuthenticate(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.029 s  <<< ERROR!
> java.lang.reflect.InvocationTargetException
> Caused by: java.io.IOException: Unable to delete file: 
> target\apacheds\cache\c68efd7d-7963-4972-b27c-c2ace6c83b63\ou=system.data
> [ERROR] 
> testAuthenticate(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.029 s  <<< ERROR!
> java.lang.NullPointerException
> [ERROR] 
> testGetGroupByRef(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.021 s  <<< ERROR
> !
> java.lang.reflect.InvocationTargetException
> Caused by: java.io.IOException: Unable to delete file: 
> target\apacheds\cache\c68efd7d-7963-4972-b27c-c2ace6c83b63\ou=system.data
> [ERROR] 
> testGetGroupByRef(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.021 s  <<< ERROR
> !
> java.lang.NullPointerException
> [ERROR] 
> testGetUnknownUserByRef(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.019 s  <<<
>  ERROR!
> java.lang.reflect.InvocationTargetException
> Caused by: java.io.IOException: Unable to delete file: 
> target\apacheds\cache\c68efd7d-7963-4972-b27c-c2ace6c83b63\ou=system.data
> [ERROR] 
> testGetUnknownUserByRef(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.019 s  <<<
>  ERROR!
> java.lang.NullPointerException
> [ERROR] 
> testGetGroups2(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.019 s  <<< ERROR!
> java.lang.reflect.InvocationTargetException
> Caused by: java.io.IOException: Unable to delete file: 
> target\apacheds\cache\c68efd7d-7963-4972-b27c-c2ace6c83b63\ou=system.data
> [ERROR] 
> testGetGroups2(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.019 s  <<< ERROR!
> java.lang.NullPointerException
> [ERROR] 
> testAuthenticateCaseInsensitive(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.02
>  s  <<< ERROR!
> java.lang.reflect.InvocationTargetException
> Caused by: java.io.IOException: Unable to delete file: 
> target\apacheds\cache\c68efd7d-7963-4972-b27c-c2ace6c83b63\ou=system.data
> [ERROR] 
> testAuthenticateCaseInsensitive(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.02
>  s  <<< ERROR!
> java.lang.NullPointerException
> [ERROR] 
> testGetGroups(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.018 s  <<< ERROR!
> java.lang.reflect.InvocationTargetException
> Caused by: java.io.IOException: Unable to delete file: 
> target\apacheds\cache\c68efd7d-7963-4972-b27c-c2ace6c83b63\ou=system.data
> [ERROR] 
> testGetGroups(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.018 s  <<< ERROR!
> java.lang.NullPointerException
> [ERROR] 
> testGetMembers(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.019 s  <<< ERROR!
> java.lang.reflect.InvocationTargetException
> Caused by: java.io.IOException: Unable to delete file: 
> target\apacheds\cache\c68efd7d-7963-4972-b27c-c2ace6c83b63\ou=system.data
> [ERROR] 
> testGetMembers(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.019 s  <<< ERROR!
> java.lang.NullPointerException
> [ERROR] 
> testGetUserByRef(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.019 s  <<< ERROR!
> java.lang.reflect.InvocationTargetException
> Caused by: java.io.IOException: Unable to delete file: 
> target\apacheds\cache\c68efd7d-7963-4972-b27c-c2ace6c83b63\ou=system.data
> [ERROR] 
> 

[jira] [Commented] (OAK-9330) Build Jackrabbit/jackrabbit-oak-trunk #131 failed

[Hudson (Jira)]

[ 
https://issues.apache.org/jira/browse/OAK-9330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17269401#comment-17269401
 ] 

Hudson commented on OAK-9330:
-

Previously failing build now is OK.
 Passed run: [Jackrabbit/jackrabbit-oak-trunk 
#133|https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-oak-trunk/133/] 
[console 
log|https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-oak-trunk/133/console]

> Build Jackrabbit/jackrabbit-oak-trunk #131 failed
> -
>
> Key: OAK-9330
> URL: https://issues.apache.org/jira/browse/OAK-9330
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: continuous integration
>Reporter: Hudson
>Priority: Major
>
> No description is provided
> The build Jackrabbit/jackrabbit-oak-trunk #131 has failed.
> First failed run: [Jackrabbit/jackrabbit-oak-trunk 
> #131|https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-oak-trunk/131/]
>  [console 
> log|https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-oak-trunk/131/console]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OAK-9324) oak-auth-ldap (UseUidForExtIdTest) tests fail (likely specific to Windows)

[Andrei Dulceanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-9324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-9324:
-
Fix Version/s: (was: 1.38.0)
   1.40.0

> oak-auth-ldap (UseUidForExtIdTest) tests fail (likely specific to Windows)
> --
>
> Key: OAK-9324
> URL: https://issues.apache.org/jira/browse/OAK-9324
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: auth-ldap
>Reporter: Julian Reschke
>Priority: Major
> Fix For: 1.40.0
>
>
> {noformat}
> [INFO] Running 
> org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest
> [ERROR] Tests run: 18, Failures: 0, Errors: 18, Skipped: 0, Time elapsed: 
> 0.184 s <<< FAILURE! - in org.apache.jackrabbit.oak.security.auth
> entication.ldap.impl.UseUidForExtIdTest
> [ERROR] 
> testAuthenticate(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.029 s  <<< ERROR!
> java.lang.reflect.InvocationTargetException
> Caused by: java.io.IOException: Unable to delete file: 
> target\apacheds\cache\c68efd7d-7963-4972-b27c-c2ace6c83b63\ou=system.data
> [ERROR] 
> testAuthenticate(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.029 s  <<< ERROR!
> java.lang.NullPointerException
> [ERROR] 
> testGetGroupByRef(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.021 s  <<< ERROR
> !
> java.lang.reflect.InvocationTargetException
> Caused by: java.io.IOException: Unable to delete file: 
> target\apacheds\cache\c68efd7d-7963-4972-b27c-c2ace6c83b63\ou=system.data
> [ERROR] 
> testGetGroupByRef(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.021 s  <<< ERROR
> !
> java.lang.NullPointerException
> [ERROR] 
> testGetUnknownUserByRef(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.019 s  <<<
>  ERROR!
> java.lang.reflect.InvocationTargetException
> Caused by: java.io.IOException: Unable to delete file: 
> target\apacheds\cache\c68efd7d-7963-4972-b27c-c2ace6c83b63\ou=system.data
> [ERROR] 
> testGetUnknownUserByRef(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.019 s  <<<
>  ERROR!
> java.lang.NullPointerException
> [ERROR] 
> testGetGroups2(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.019 s  <<< ERROR!
> java.lang.reflect.InvocationTargetException
> Caused by: java.io.IOException: Unable to delete file: 
> target\apacheds\cache\c68efd7d-7963-4972-b27c-c2ace6c83b63\ou=system.data
> [ERROR] 
> testGetGroups2(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.019 s  <<< ERROR!
> java.lang.NullPointerException
> [ERROR] 
> testAuthenticateCaseInsensitive(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.02
>  s  <<< ERROR!
> java.lang.reflect.InvocationTargetException
> Caused by: java.io.IOException: Unable to delete file: 
> target\apacheds\cache\c68efd7d-7963-4972-b27c-c2ace6c83b63\ou=system.data
> [ERROR] 
> testAuthenticateCaseInsensitive(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.02
>  s  <<< ERROR!
> java.lang.NullPointerException
> [ERROR] 
> testGetGroups(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.018 s  <<< ERROR!
> java.lang.reflect.InvocationTargetException
> Caused by: java.io.IOException: Unable to delete file: 
> target\apacheds\cache\c68efd7d-7963-4972-b27c-c2ace6c83b63\ou=system.data
> [ERROR] 
> testGetGroups(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.018 s  <<< ERROR!
> java.lang.NullPointerException
> [ERROR] 
> testGetMembers(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.019 s  <<< ERROR!
> java.lang.reflect.InvocationTargetException
> Caused by: java.io.IOException: Unable to delete file: 
> target\apacheds\cache\c68efd7d-7963-4972-b27c-c2ace6c83b63\ou=system.data
> [ERROR] 
> testGetMembers(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.019 s  <<< ERROR!
> java.lang.NullPointerException
> [ERROR] 
> testGetUserByRef(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.019 s  <<< ERROR!
> java.lang.reflect.InvocationTargetException
> Caused by: java.io.IOException: Unable to delete file: 
> target\apacheds\cache\c68efd7d-7963-4972-b27c-c2ace6c83b63\ou=system.data
> [ERROR] 
> 

[jira] [Commented] (OAK-9331) JavaDoc generation fails on Java 15

[Fabrizio Fortino (Jira)]

[ 
https://issues.apache.org/jira/browse/OAK-9331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17269322#comment-17269322
 ] 

Fabrizio Fortino commented on OAK-9331:
---

[~adulceanu] I think that merging the latest changes from trunk will make the 
errors go away. Some class modifiers have been changed with this commit 
([https://github.com/apache/jackrabbit-oak/commit/8e6049c06a27b5dae87eb2c84daee2ac9df6739e)]
 but it seems you only have partial changes.

> JavaDoc generation fails on Java 15
> ---
>
> Key: OAK-9331
> URL: https://issues.apache.org/jira/browse/OAK-9331
> Project: Jackrabbit Oak
>  Issue Type: Bug
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Major
> Attachments: OAK-9331-01.patch
>
>
> {{mvn javadoc:javadoc}} fails on Java 15 with:
> {noformat}
> /apache/jackrabbit-oak/oak-security-spi/src/main/java/org/apache/jackrabbit/oak/spi/security/principal/PrincipalConfiguration.java:48:
>  error: unexpected heading used: , compared to implicit preceding 
> heading: 
> [ERROR]  * Backwards compatibility with Jackrabbit 2.x
> [ERROR]^
> {noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OAK-9324) oak-auth-ldap (UseUidForExtIdTest) tests fail (likely specific to Windows)

[Andrei Dulceanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-9324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-9324:
-
Fix Version/s: (was: 1.40.0)
   1.38.0

> oak-auth-ldap (UseUidForExtIdTest) tests fail (likely specific to Windows)
> --
>
> Key: OAK-9324
> URL: https://issues.apache.org/jira/browse/OAK-9324
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: auth-ldap
>Reporter: Julian Reschke
>Priority: Major
> Fix For: 1.38.0
>
>
> {noformat}
> [INFO] Running 
> org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest
> [ERROR] Tests run: 18, Failures: 0, Errors: 18, Skipped: 0, Time elapsed: 
> 0.184 s <<< FAILURE! - in org.apache.jackrabbit.oak.security.auth
> entication.ldap.impl.UseUidForExtIdTest
> [ERROR] 
> testAuthenticate(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.029 s  <<< ERROR!
> java.lang.reflect.InvocationTargetException
> Caused by: java.io.IOException: Unable to delete file: 
> target\apacheds\cache\c68efd7d-7963-4972-b27c-c2ace6c83b63\ou=system.data
> [ERROR] 
> testAuthenticate(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.029 s  <<< ERROR!
> java.lang.NullPointerException
> [ERROR] 
> testGetGroupByRef(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.021 s  <<< ERROR
> !
> java.lang.reflect.InvocationTargetException
> Caused by: java.io.IOException: Unable to delete file: 
> target\apacheds\cache\c68efd7d-7963-4972-b27c-c2ace6c83b63\ou=system.data
> [ERROR] 
> testGetGroupByRef(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.021 s  <<< ERROR
> !
> java.lang.NullPointerException
> [ERROR] 
> testGetUnknownUserByRef(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.019 s  <<<
>  ERROR!
> java.lang.reflect.InvocationTargetException
> Caused by: java.io.IOException: Unable to delete file: 
> target\apacheds\cache\c68efd7d-7963-4972-b27c-c2ace6c83b63\ou=system.data
> [ERROR] 
> testGetUnknownUserByRef(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.019 s  <<<
>  ERROR!
> java.lang.NullPointerException
> [ERROR] 
> testGetGroups2(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.019 s  <<< ERROR!
> java.lang.reflect.InvocationTargetException
> Caused by: java.io.IOException: Unable to delete file: 
> target\apacheds\cache\c68efd7d-7963-4972-b27c-c2ace6c83b63\ou=system.data
> [ERROR] 
> testGetGroups2(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.019 s  <<< ERROR!
> java.lang.NullPointerException
> [ERROR] 
> testAuthenticateCaseInsensitive(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.02
>  s  <<< ERROR!
> java.lang.reflect.InvocationTargetException
> Caused by: java.io.IOException: Unable to delete file: 
> target\apacheds\cache\c68efd7d-7963-4972-b27c-c2ace6c83b63\ou=system.data
> [ERROR] 
> testAuthenticateCaseInsensitive(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.02
>  s  <<< ERROR!
> java.lang.NullPointerException
> [ERROR] 
> testGetGroups(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.018 s  <<< ERROR!
> java.lang.reflect.InvocationTargetException
> Caused by: java.io.IOException: Unable to delete file: 
> target\apacheds\cache\c68efd7d-7963-4972-b27c-c2ace6c83b63\ou=system.data
> [ERROR] 
> testGetGroups(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.018 s  <<< ERROR!
> java.lang.NullPointerException
> [ERROR] 
> testGetMembers(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.019 s  <<< ERROR!
> java.lang.reflect.InvocationTargetException
> Caused by: java.io.IOException: Unable to delete file: 
> target\apacheds\cache\c68efd7d-7963-4972-b27c-c2ace6c83b63\ou=system.data
> [ERROR] 
> testGetMembers(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.019 s  <<< ERROR!
> java.lang.NullPointerException
> [ERROR] 
> testGetUserByRef(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.019 s  <<< ERROR!
> java.lang.reflect.InvocationTargetException
> Caused by: java.io.IOException: Unable to delete file: 
> target\apacheds\cache\c68efd7d-7963-4972-b27c-c2ace6c83b63\ou=system.data
> [ERROR] 
> 

[jira] [Commented] (OAK-9332) Document best practices and anti-patterns in repository tree traversal

[Angela Schreiber (Jira)]

[ 
https://issues.apache.org/jira/browse/OAK-9332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17269287#comment-17269287
 ] 

Angela Schreiber commented on OAK-9332:
---

[~miroslav], regarding best practices regarding tree traversal specifically: 
each {{SecureNodeState}} will keep have a {{TreePermission}} object associated, 
that may (and in the default impl does) cache the result of previous 
evaluations e.g. if the node is readable or the remember the set of effective 
entries to use for the evaluation. afaik {{session.getNode("/a/b/c/d")}} will 
instead start creating the hierarchy from scratch and thus builds the tree 
objects (including nodestates and treepermissions) again.

> Document best practices and anti-patterns in repository tree traversal  
> 
>
> Key: OAK-9332
> URL: https://issues.apache.org/jira/browse/OAK-9332
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: doc
>Reporter: Miroslav Smiljanic
>Priority: Major
>
> When using JCR API, there is more than one way to perform tree/path traversal:
> {code:java}
> Node c = session.getNode("/a/b/c");
> Node d = null;
> //get child node
> d = session.getNode("/a/b/c/d");
> d = c.getNode("d");
> // get parent node
> c = d.getParent();
> c = session.getNode("/a/b/c");
> {code}
> To traverse a path using Node API with  performs better compared to Session 
> API. 
> {noformat}
> > java -jar target/oak-benchmarks-*-SNAPSHOT.jar benchmark  
> > GetParentNodeWithNodeAPI  GetParentNodeWithSessionAPI  Oak-Segment-Tar
> Apache Jackrabbit Oak 1.37-SNAPSHOT
> # GetParentNodeWithNodeAPI C min 10% 50% 90% max  
>N   mean 
> Oak-Segment-Tar1   2   2   2   3  5   
> 25891   2
> # GetParentNodeWithSessionAP   C min 10% 50% 90% max  
>N   mean 
> Oak-Segment-Tar1  26  27  29  32 40   
>  2069  29{noformat}
> Example where Session API is used: 
> https://issues.apache.org/jira/browse/SLING-10011
> Considering Oak implementation details (tree repository structure, ACL 
> evaluation, ...) the best practice for path traversal should be explicitly 
> documented.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (OAK-9330) Build Jackrabbit/jackrabbit-oak-trunk #131 failed

[Hudson (Jira)]

[ 
https://issues.apache.org/jira/browse/OAK-9330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17269285#comment-17269285
 ] 

Hudson commented on OAK-9330:
-

Build is still failing.
Failed run: [Jackrabbit/jackrabbit-oak-trunk 
#132|https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-oak-trunk/132/] 
[console 
log|https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-oak-trunk/132/console]

> Build Jackrabbit/jackrabbit-oak-trunk #131 failed
> -
>
> Key: OAK-9330
> URL: https://issues.apache.org/jira/browse/OAK-9330
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: continuous integration
>Reporter: Hudson
>Priority: Major
>
> No description is provided
> The build Jackrabbit/jackrabbit-oak-trunk #131 has failed.
> First failed run: [Jackrabbit/jackrabbit-oak-trunk 
> #131|https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-oak-trunk/131/]
>  [console 
> log|https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-oak-trunk/131/console]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Comment Edited] (OAK-9332) Document best practices and anti-patterns in repository tree traversal

[Angela Schreiber (Jira)]

[ 
https://issues.apache.org/jira/browse/OAK-9332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17269274#comment-17269274
 ] 

Angela Schreiber edited comment on OAK-9332 at 1/21/21, 12:54 PM:
--

[~miroslav], thanks for initiating this. looking at the documentation i found 
we have a few things documented in the _dos_and_donts.md_. so just from the top 
of my head a few ideas (definitely not a comprehensive list) for general 
best-practices when using oak.

access control setup:
- model your JCR hierarchies with access control requirements in mind
- use 'principle of least privilege': only grant privileges absolutely needed
- limit the scope of your access control setup by identifying the items that 
need to be accessible/writable
- use allowing access control entries, try to avoid denies and remember that no 
access control setup is an implicit deny
- avoid access control setup for regular user principals, grant access for 
group principals instead
- access control setup for system user: leverage principal-based access control 
if available in your security setup. this avoids mixing permissions for your 
application with non-application content
- avoid redundant ac setup. effective permissions are inherited down the 
hierarchy and through declared and inherited group membership
 
user mgt:
- when adding/removing multiple members use {{Group.addMembers(@NotNull 
String... memberIds)}} and {{Group.removeMembers(@NotNull String... 
memberIds)}} instead {{Group.addMember}} and {{Group.removeMember}}

regarding general jcr usage:
- use oak:Unstructured instead of nt:unstructured if childnodes don't have an 
order

depending on how low the list gets in the end we might move the best-practices 
to the individual sections and then link it from the general 'best-practices' 
page as we do e.g. in the _error_codes.md_


was (Author: anchela):
[~miroslav], thanks for initiating this. looking at the documentation i found 
we have a few things documented in the _dos_and_donts.md_. so just from the top 
of my head a few ideas (definitely not a comprehensive list)

access control setup:
- model your JCR hierarchies with access control requirements in mind
- use 'principle of least privilege': only grant privileges absolutely needed
- limit the scope of your access control setup by identifying the items that 
need to be accessible/writable
- use allowing access control entries, try to avoid denies and remember that no 
access control setup is an implicit deny
- avoid access control setup for regular user principals, grant access for 
group principals instead
- access control setup for system user: leverage principal-based access control 
if available in your security setup. this avoids mixing permissions for your 
application with non-application content
- avoid redundant ac setup. effective permissions are inherited down the 
hierarchy and through declared and inherited group membership
 
user mgt:
- when adding/removing multiple members use {{Group.addMembers(@NotNull 
String... memberIds)}} and {{Group.removeMembers(@NotNull String... 
memberIds)}} instead {{Group.addMember}} and {{Group.removeMember}}

regarding general jcr usage:
- use oak:Unstructured instead of nt:unstructured if childnodes don't have an 
order

depending on how low the list gets in the end we might move the best-practices 
to the individual sections and then link it from the general 'best-practices' 
page as we do e.g. in the _error_codes.md_

> Document best practices and anti-patterns in repository tree traversal  
> 
>
> Key: OAK-9332
> URL: https://issues.apache.org/jira/browse/OAK-9332
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: doc
>Reporter: Miroslav Smiljanic
>Priority: Major
>
> When using JCR API, there is more than one way to perform tree/path traversal:
> {code:java}
> Node c = session.getNode("/a/b/c");
> Node d = null;
> //get child node
> d = session.getNode("/a/b/c/d");
> d = c.getNode("d");
> // get parent node
> c = d.getParent();
> c = session.getNode("/a/b/c");
> {code}
> To traverse a path using Node API with  performs better compared to Session 
> API. 
> {noformat}
> > java -jar target/oak-benchmarks-*-SNAPSHOT.jar benchmark  
> > GetParentNodeWithNodeAPI  GetParentNodeWithSessionAPI  Oak-Segment-Tar
> Apache Jackrabbit Oak 1.37-SNAPSHOT
> # GetParentNodeWithNodeAPI C min 10% 50% 90% max  
>N   mean 
> Oak-Segment-Tar1   2   2   2   3  5   
> 25891   2
> # GetParentNodeWithSessionAP   C min 10% 50% 90% max  
>N   mean 
> Oak-Segment-Tar1  26  27  29  32 40   
>  2069  29{noformat}
> Example where 

[jira] [Comment Edited] (OAK-9332) Document best practices and anti-patterns in repository tree traversal

[Angela Schreiber (Jira)]

[ 
https://issues.apache.org/jira/browse/OAK-9332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17269274#comment-17269274
 ] 

Angela Schreiber edited comment on OAK-9332 at 1/21/21, 12:54 PM:
--

[~miroslav], thanks for initiating this. looking at the documentation i found 
we have a few things documented in the _dos_and_donts.md_. so just from the top 
of my head a few ideas (definitely not a comprehensive list)

access control setup:
- model your JCR hierarchies with access control requirements in mind
- use 'principle of least privilege': only grant privileges absolutely needed
- limit the scope of your access control setup by identifying the items that 
need to be accessible/writable
- use allowing access control entries, try to avoid denies and remember that no 
access control setup is an implicit deny
- avoid access control setup for regular user principals, grant access for 
group principals instead
- access control setup for system user: leverage principal-based access control 
if available in your security setup. this avoids mixing permissions for your 
application with non-application content
- avoid redundant ac setup. effective permissions are inherited down the 
hierarchy and through declared and inherited group membership
 
user mgt:
- when adding/removing multiple members use {{Group.addMembers(@NotNull 
String... memberIds)}} and {{Group.removeMembers(@NotNull String... 
memberIds)}} instead {{Group.addMember}} and {{Group.removeMember}}

regarding general jcr usage:
- use oak:Unstructured instead of nt:unstructured if childnodes don't have an 
order

depending on how low the list gets in the end we might move the best-practices 
to the individual sections and then link it from the general 'best-practices' 
page as we do e.g. in the _error_codes.md_


was (Author: anchela):
[~miroslav], thanks for initiating this. looking at the documentation i found 
we have a few things documented in the _dos_and_donts.md_. so just from the top 
of my head a few ideas (definitely not a comprehensive list0

access control setup:
- model your JCR hierarchies with access control requirements in mind
- use 'principle of least privilege': only grant privileges absolutely needed
- limit the scope of your access control setup by identifying the items that 
need to be accessible/writable
- use allowing access control entries, try to avoid denies and remember that no 
access control setup is an implicit deny
- avoid access control setup for regular user principals, grant access for 
group principals instead
- access control setup for system user: leverage principal-based access control 
if available in your security setup. this avoids mixing permissions for your 
application with non-application content
- avoid redundant ac setup. effective permissions are inherited down the 
hierarchy and through declared and inherited group membership
 
user mgt:
- when adding/removing multiple members use {{Group.addMembers(@NotNull 
String... memberIds)}} and {{Group.removeMembers(@NotNull String... 
memberIds)}} instead {{Group.addMember}} and {{Group.removeMember}}

regarding general jcr usage:
- use oak:Unstructured instead of nt:unstructured if childnodes don't have an 
order

depending on how low the list gets in the end we might move the best-practices 
to the individual sections and then link it from the general 'best-practices' 
page as we do e.g. in the _error_codes.md_

> Document best practices and anti-patterns in repository tree traversal  
> 
>
> Key: OAK-9332
> URL: https://issues.apache.org/jira/browse/OAK-9332
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: doc
>Reporter: Miroslav Smiljanic
>Priority: Major
>
> When using JCR API, there is more than one way to perform tree/path traversal:
> {code:java}
> Node c = session.getNode("/a/b/c");
> Node d = null;
> //get child node
> d = session.getNode("/a/b/c/d");
> d = c.getNode("d");
> // get parent node
> c = d.getParent();
> c = session.getNode("/a/b/c");
> {code}
> To traverse a path using Node API with  performs better compared to Session 
> API. 
> {noformat}
> > java -jar target/oak-benchmarks-*-SNAPSHOT.jar benchmark  
> > GetParentNodeWithNodeAPI  GetParentNodeWithSessionAPI  Oak-Segment-Tar
> Apache Jackrabbit Oak 1.37-SNAPSHOT
> # GetParentNodeWithNodeAPI C min 10% 50% 90% max  
>N   mean 
> Oak-Segment-Tar1   2   2   2   3  5   
> 25891   2
> # GetParentNodeWithSessionAP   C min 10% 50% 90% max  
>N   mean 
> Oak-Segment-Tar1  26  27  29  32 40   
>  2069  29{noformat}
> Example where Session API is used: 
> 

[jira] [Comment Edited] (OAK-9332) Document best practices and anti-patterns in repository tree traversal

[Angela Schreiber (Jira)]

[ 
https://issues.apache.org/jira/browse/OAK-9332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17269274#comment-17269274
 ] 

Angela Schreiber edited comment on OAK-9332 at 1/21/21, 12:52 PM:
--

[~miroslav], thanks for initiating this. looking at the documentation i found 
we have a few things documented in the _dos_and_donts.md_. so just from the top 
of my head a few ideas (definitely not a comprehensive list0

access control setup:
- model your JCR hierarchies with access control requirements in mind
- use 'principle of least privilege': only grant privileges absolutely needed
- limit the scope of your access control setup by identifying the items that 
need to be accessible/writable
- use allowing access control entries, try to avoid denies and remember that no 
access control setup is an implicit deny
- avoid access control setup for regular user principals, grant access for 
group principals instead
- access control setup for system user: leverage principal-based access control 
if available in your security setup. this avoids mixing permissions for your 
application with non-application content
- avoid redundant ac setup. effective permissions are inherited down the 
hierarchy and through declared and inherited group membership
 
user mgt:
- when adding/removing multiple members use {{Group.addMembers(@NotNull 
String... memberIds)}} and {{Group.removeMembers(@NotNull String... 
memberIds)}} instead {{Group.addMember}} and {{Group.removeMember}}

regarding general jcr usage:
- use oak:Unstructured instead of nt:unstructured if childnodes don't have an 
order

depending on how low the list gets in the end we might move the best-practices 
to the individual sections and then link it from the general 'best-practices' 
page as we do e.g. in the _error_codes.md_


was (Author: anchela):
[~miroslav], thanks for initiating this. looking at the documentation i found 
we have a few things documented in the _dos_and_donts.md_. so just from the top 
of my head a few ideas (definitely not a comprehensive list0

access control setup:
- model your JCR hierarchies with access control requirements in mind
- use 'principle of least privilege': only grant privileges absolutely needed
- limit the scope of your access control setup by identifying the items that 
need to be accessible/writable
- use allowing access control entries, try to avoid denies and remember that no 
access control setup is an implicit deny
- avoid access control setup for regular user principals, grant access for 
group principals instead
- access control setup for system user: leverage principal-based access control 
if available in your security setup. this avoids mixing permissions for your 
application with non-application content
- avoid redundant ac setup. effective permissions are inherited down the 
hierarchy and through declared and inherited group membership
 
regarding general jcr usage:
- use oak:Unstructured instead of nt:unstructured if childnodes don't have an 
order

depending on how low the list gets in the end we might move the best-practices 
to the individual sections and then link it from the general 'best-practices' 
page as we do e.g. in the _error_codes.md_

> Document best practices and anti-patterns in repository tree traversal  
> 
>
> Key: OAK-9332
> URL: https://issues.apache.org/jira/browse/OAK-9332
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: doc
>Reporter: Miroslav Smiljanic
>Priority: Major
>
> When using JCR API, there is more than one way to perform tree/path traversal:
> {code:java}
> Node c = session.getNode("/a/b/c");
> Node d = null;
> //get child node
> d = session.getNode("/a/b/c/d");
> d = c.getNode("d");
> // get parent node
> c = d.getParent();
> c = session.getNode("/a/b/c");
> {code}
> To traverse a path using Node API with  performs better compared to Session 
> API. 
> {noformat}
> > java -jar target/oak-benchmarks-*-SNAPSHOT.jar benchmark  
> > GetParentNodeWithNodeAPI  GetParentNodeWithSessionAPI  Oak-Segment-Tar
> Apache Jackrabbit Oak 1.37-SNAPSHOT
> # GetParentNodeWithNodeAPI C min 10% 50% 90% max  
>N   mean 
> Oak-Segment-Tar1   2   2   2   3  5   
> 25891   2
> # GetParentNodeWithSessionAP   C min 10% 50% 90% max  
>N   mean 
> Oak-Segment-Tar1  26  27  29  32 40   
>  2069  29{noformat}
> Example where Session API is used: 
> https://issues.apache.org/jira/browse/SLING-10011
> Considering Oak implementation details (tree repository structure, ACL 
> evaluation, ...) the best practice for path traversal should be explicitly 
> documented.



--
This message was sent 

[jira] [Commented] (OAK-9332) Document best practices and anti-patterns in repository tree traversal

[Angela Schreiber (Jira)]

[ 
https://issues.apache.org/jira/browse/OAK-9332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17269274#comment-17269274
 ] 

Angela Schreiber commented on OAK-9332:
---

[~miroslav], thanks for initiating this. looking at the documentation i found 
we have a few things documented in the _dos_and_donts.md_. so just from the top 
of my head a few ideas (definitely not a comprehensive list0

access control setup:
- model your JCR hierarchies with access control requirements in mind
- use 'principle of least privilege': only grant privileges absolutely needed
- limit the scope of your access control setup by identifying the items that 
need to be accessible/writable
- use allowing access control entries, try to avoid denies and remember that no 
access control setup is an implicit deny
- avoid access control setup for regular user principals, grant access for 
group principals instead
- access control setup for system user: leverage principal-based access control 
if available in your security setup. this avoids mixing permissions for your 
application with non-application content
- avoid redundant ac setup. effective permissions are inherited down the 
hierarchy and through declared and inherited group membership
 
regarding general jcr usage:
- use oak:Unstructured instead of nt:unstructured if childnodes don't have an 
order

depending on how low the list gets in the end we might move the best-practices 
to the individual sections and then link it from the general 'best-practices' 
page as we do e.g. in the _error_codes.md_

> Document best practices and anti-patterns in repository tree traversal  
> 
>
> Key: OAK-9332
> URL: https://issues.apache.org/jira/browse/OAK-9332
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: doc
>Reporter: Miroslav Smiljanic
>Priority: Major
>
> When using JCR API, there is more than one way to perform tree/path traversal:
> {code:java}
> Node c = session.getNode("/a/b/c");
> Node d = null;
> //get child node
> d = session.getNode("/a/b/c/d");
> d = c.getNode("d");
> // get parent node
> c = d.getParent();
> c = session.getNode("/a/b/c");
> {code}
> To traverse a path using Node API with  performs better compared to Session 
> API. 
> {noformat}
> > java -jar target/oak-benchmarks-*-SNAPSHOT.jar benchmark  
> > GetParentNodeWithNodeAPI  GetParentNodeWithSessionAPI  Oak-Segment-Tar
> Apache Jackrabbit Oak 1.37-SNAPSHOT
> # GetParentNodeWithNodeAPI C min 10% 50% 90% max  
>N   mean 
> Oak-Segment-Tar1   2   2   2   3  5   
> 25891   2
> # GetParentNodeWithSessionAP   C min 10% 50% 90% max  
>N   mean 
> Oak-Segment-Tar1  26  27  29  32 40   
>  2069  29{noformat}
> Example where Session API is used: 
> https://issues.apache.org/jira/browse/SLING-10011
> Considering Oak implementation details (tree repository structure, ACL 
> evaluation, ...) the best practice for path traversal should be explicitly 
> documented.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OAK-6408) Review package exports for o.a.j.oak.plugins.index.*

[Andrei Dulceanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-6408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-6408:
-
Fix Version/s: (was: 1.38.0)
   1.40.0

> Review package exports for o.a.j.oak.plugins.index.*
> 
>
> Key: OAK-6408
> URL: https://issues.apache.org/jira/browse/OAK-6408
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: core, indexing
>Reporter: Angela Schreiber
>Priority: Major
> Fix For: 1.40.0
>
>
> while working on OAK-6304 and OAK-6355, i noticed that the 
> _o.a.j.oak.plugins.index.*_ contains both internal api/utilities and 
> implementation details which get equally exported (though without having any 
> package export version set).
> in the light of the modularization effort, i would like to suggest that we 
> try to sort that out and separate the _public_ parts from implementation 
> details. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OAK-6421) Phase out JCR Locking support

[Andrei Dulceanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-6421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-6421:
-
Fix Version/s: (was: 1.38.0)
   1.40.0

> Phase out JCR Locking support
> -
>
> Key: OAK-6421
> URL: https://issues.apache.org/jira/browse/OAK-6421
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: jcr
>Reporter: Marcel Reutegger
>Priority: Major
> Fix For: 1.40.0
>
>
> Oak currently has a lot of gaps in its JCR Locking implementation (see 
> OAK-1962), which basically makes it non-compliant with the JCR specification.
> I propose we phase out the support for JCR Locking because a proper 
> implementation would be rather complex with a runtime behaviour that is very 
> different in a standalone deployment compared to a cluster. In the standalone 
> case a lock could be acquired very quickly, while in the distributed case, 
> the operations would be multiple orders of magnitude slower, depending on how 
> cluster nodes are geographically distributed.
> Applications that rely on strict lock semantics should use other mechanisms, 
> built explicitly for this purpose. E.g. Apache Zookeeper.
> To ease upgrade and migration to a different lock mechanism, the proposal is 
> to introduce a flag or configuration that controls the level of support for 
> JCR Locking:
> - DISABLED: the implementation does not support JCR Locking at all. Methods 
> will throw UnsupportedRepositoryOperationException when defined by the JCR 
> specification. 
> - DEPRECATED: the implementation behaves as right now, but logs a warn or 
> error message that JCR Locking does not work as specified and will be removed 
> in a future version of Oak.
> In a later release (e.g. 1.10) the current JCR Locking implementation would 
> be removed entirely and unconditionally throw an exception.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OAK-5917) Document enhancements in indexing in 1.6

[Andrei Dulceanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-5917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-5917:
-
Fix Version/s: (was: 1.38.0)
   1.40.0

> Document enhancements in indexing in 1.6
> 
>
> Key: OAK-5917
> URL: https://issues.apache.org/jira/browse/OAK-5917
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: doc
>Reporter: Chetan Mehrotra
>Assignee: Thomas Mueller
>Priority: Major
> Fix For: 1.40.0
>
>
> This task is meant to collect and refer work done in 1.6 release which needs 
> to be documented in Oak docs.
> Issues in lucene and query area 
> [jql|https://issues.apache.org/jira/issues/?jql=project%20%3D%20OAK%20AND%20fixVersion%20%3D%201.6.0%20and%20component%20in%20(lucene%2C%20query)%20ORDER%20BY%20updated%20DESC%2C%20priority%20DESC%2C%20created%20ASC]
> Topics to cover
> * OAK-4412 - Lucene Hybrid Index (/)
> * OAK-4939 - Isolation of corrupted index  (/)
> * OAK-4974 - Enable configuring QueryEngineSettings via OSGi config 
> * OAK-3574 - Function based indexes
> * OAK-4400 - Correlate index with the index definition used to build it  (/)



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OAK-6904) NRT Indexes should be closed if async indexer progresses

[Andrei Dulceanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-6904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-6904:
-
Fix Version/s: (was: 1.38.0)
   1.40.0

> NRT Indexes should be closed if async indexer progresses
> 
>
> Key: OAK-6904
> URL: https://issues.apache.org/jira/browse/OAK-6904
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: lucene
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: 1.40.0
>
>
> Currently NRTIndex associated with IndexNodeManager are only closed upon 
> index update. However each IndexNodeManager keeps reference to 2 NRTIndex 
> instances. It can happen that following sequence can happen
> # Index /oak:index/ntBaseLucene refers to 2 nrt indexes NR1 and NR2. Where 
> NR1 has 1 M entries and NR2 has 1 M entries
> # AsyncIndexer updates and thus refreshes the /oak:index/ntBaseLucene. This 
> causes new NRT Index NR3 to be created and NR1 to be closed. So NR3 and NR2 
> are active
> # AsyncIndexer updates but no change happen in setup which causes any update 
> to /oak:index/ntBaseLucene. Thus this index does not get refreshed and 
> continues to refer to NR2 
> So as a fix we should refresh any index if it refers to 2 NRT indexes where 
> previous one is not empty



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OAK-3373) Observers dont survive store restart (was: LuceneIndexProvider: java.lang.IllegalStateException: open)

[Andrei Dulceanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-3373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-3373:
-
Fix Version/s: (was: 1.38.0)
   1.40.0

> Observers dont survive store restart (was: LuceneIndexProvider: 
> java.lang.IllegalStateException: open)
> --
>
> Key: OAK-3373
> URL: https://issues.apache.org/jira/browse/OAK-3373
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.3.5
>Reporter: Stefan Egli
>Priority: Minor
> Fix For: 1.40.0
>
>
> The following exception occurs when stopping, then immediately re-starting 
> the oak-core bundle (which was done as part of testing for OAK-3250 - but can 
> be reproduced independently). It's not clear what the consequences are 
> though..
> {code}08.09.2015 14:20:26.960 *ERROR* [oak-lucene-0] 
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexProvider Uncaught 
> exception in 
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexProvider@3a4a6c5c
> org.apache.jackrabbit.oak.plugins.document.DocumentStoreException: Error 
> occurred while fetching children for path /oak:index/authorizables
> at 
> org.apache.jackrabbit.oak.plugins.document.DocumentStoreException.convert(DocumentStoreException.java:48)
> at 
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.getChildren(DocumentNodeStore.java:902)
> at 
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.getChildNodes(DocumentNodeStore.java:1082)
> at 
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeState.getChildNodeEntries(DocumentNodeState.java:508)
> at 
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeState.access$100(DocumentNodeState.java:65)
> at 
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeState$ChildNodeEntryIterator.fetchMore(DocumentNodeState.java:716)
> at 
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeState$ChildNodeEntryIterator.(DocumentNodeState.java:681)
> at 
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeState$1.iterator(DocumentNodeState.java:289)
> at 
> org.apache.jackrabbit.oak.spi.state.AbstractNodeState.compareAgainstBaseState(AbstractNodeState.java:129)
> at 
> org.apache.jackrabbit.oak.spi.state.AbstractNodeState.compareAgainstBaseState(AbstractNodeState.java:303)
> at 
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeState.compareAgainstBaseState(DocumentNodeState.java:359)
> at 
> org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeChanged(EditorDiff.java:148)
> at 
> org.apache.jackrabbit.oak.spi.state.AbstractNodeState.compareAgainstBaseState(AbstractNodeState.java:140)
> at 
> org.apache.jackrabbit.oak.spi.state.AbstractNodeState.compareAgainstBaseState(AbstractNodeState.java:303)
> at 
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeState.compareAgainstBaseState(DocumentNodeState.java:359)
> at 
> org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeChanged(EditorDiff.java:148)
> at 
> org.apache.jackrabbit.oak.spi.state.AbstractNodeState.compareAgainstBaseState(AbstractNodeState.java:140)
> at 
> org.apache.jackrabbit.oak.spi.state.AbstractNodeState.compareAgainstBaseState(AbstractNodeState.java:303)
> at 
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeState.compareAgainstBaseState(DocumentNodeState.java:359)
> at 
> org.apache.jackrabbit.oak.spi.commit.EditorDiff.process(EditorDiff.java:52)
> at 
> org.apache.jackrabbit.oak.plugins.index.lucene.IndexTracker.update(IndexTracker.java:108)
> at 
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexProvider.contentChanged(LuceneIndexProvider.java:73)
> at 
> org.apache.jackrabbit.oak.spi.commit.BackgroundObserver$1$1.call(BackgroundObserver.java:127)
> at 
> org.apache.jackrabbit.oak.spi.commit.BackgroundObserver$1$1.call(BackgroundObserver.java:121)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.IllegalStateException: open
> at org.bson.util.Assertions.isTrue(Assertions.java:36)
> at 
> com.mongodb.DBTCPConnector.isMongosConnection(DBTCPConnector.java:367)
> at com.mongodb.Mongo.isMongosConnection(Mongo.java:622)
> at com.mongodb.DBCursor._check(DBCursor.java:494)
> at com.mongodb.DBCursor._hasNext(DBCursor.java:621)
> at 

[jira] [Updated] (OAK-5655) TarMK: Analyse locality of reference

[Andrei Dulceanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-5655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-5655:
-
Fix Version/s: (was: 1.38.0)
   1.40.0

> TarMK: Analyse locality of reference 
> -
>
> Key: OAK-5655
> URL: https://issues.apache.org/jira/browse/OAK-5655
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: segment-tar
>Reporter: Michael Dürig
>Priority: Major
>  Labels: scalability
> Fix For: 1.40.0
>
> Attachments: compaction-time-vs-reposize.m, 
> compaction-time-vs.reposize.png, data00053a.tar-reads.png, offrc.jfr, 
> segment-per-path-compacted-nocache.png, 
> segment-per-path-compacted-nostringcache.png, segment-per-path-compacted.png, 
> segment-per-path.png, segment-reads.png
>
>
> We need to better understand the locality aspects of content stored in TarMK: 
> * How is related content spread over segments?
> * What content do we consider related? 
> * How does locality of related content develop over time when changes are 
> applied?
> * What changes do we consider typical?
> * What is the impact of compaction on locality? 
> * What is the impact of the deduplication caches on locality (during normal 
> operation and during compaction)?
> * How good are checkpoints deduplicated? Can we monitor this online?
> * ...



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OAK-7382) Cloud datastore without local disk

[Andrei Dulceanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-7382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-7382:
-
Fix Version/s: (was: 1.38.0)
   1.40.0

> Cloud datastore without local disk
> --
>
> Key: OAK-7382
> URL: https://issues.apache.org/jira/browse/OAK-7382
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: blob, blob-cloud
>Reporter: Thomas Mueller
>Assignee: Amit Jain
>Priority: Major
> Fix For: 1.40.0
>
>
> Currently, the S3 datastores need local disk to work (not sure about the 
> Azure one).
> This should not be needed (not for upload, caching,...).
> Also, temporary files for garbage collection should not be needed (instead, 
> use temporary binaries, possibly written to S3 / Azure).
> Really everything should fit in a few MB of memory.
> For S3, it might be needed to read a few MB of data into memory, and then 
> possibly do a multipart upload:
>  
> https://stackoverflow.com/questions/8653146/can-i-stream-a-file-upload-to-s3-without-a-content-length-header



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OAK-6774) Convert oak-upgrade to OSGi R6 annotations

[Andrei Dulceanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-6774:
-
Fix Version/s: (was: 1.38.0)
   1.40.0

> Convert oak-upgrade to OSGi R6 annotations
> --
>
> Key: OAK-6774
> URL: https://issues.apache.org/jira/browse/OAK-6774
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: upgrade
>Reporter: Robert Munteanu
>Priority: Major
> Fix For: 1.40.0
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OAK-7634) Repository migration docs should include info on TAR <-> Azure sidegrade

[Andrei Dulceanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-7634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-7634:
-
Fix Version/s: (was: 1.38.0)
   1.40.0

> Repository migration docs should include info on TAR <-> Azure sidegrade
> 
>
> Key: OAK-7634
> URL: https://issues.apache.org/jira/browse/OAK-7634
> Project: Jackrabbit Oak
>  Issue Type: Documentation
>  Components: doc, segment-tar
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Minor
> Fix For: 1.40.0
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OAK-4814) Add orderby support for nodename index

[Andrei Dulceanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-4814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-4814:
-
Fix Version/s: (was: 1.38.0)
   1.40.0

> Add orderby support for nodename index
> --
>
> Key: OAK-4814
> URL: https://issues.apache.org/jira/browse/OAK-4814
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: query
>Affects Versions: 1.5.10
>Reporter: Ankush Malhotra
>Assignee: Vikas Saurabh
>Priority: Major
> Fix For: 1.40.0
>
>
> In OAK-1752 you have implemented the index support for :nodeName. The JCR 
> Query explain tool shows that it is used for conditions like equals.
> But it is not used for ORDER BY name() .
> Is name() supported in order by clause? If yes then we would need to add 
> support for that in oak-lucene



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OAK-9024) oak-solr-osgi imports org.slf4j.impl

[Andrei Dulceanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-9024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-9024:
-
Fix Version/s: (was: 1.38.0)
   1.40.0

> oak-solr-osgi imports org.slf4j.impl
> 
>
> Key: OAK-9024
> URL: https://issues.apache.org/jira/browse/OAK-9024
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: solr
>Reporter: Julian Reschke
>Assignee: Manfred Baedke
>Priority: Minor
> Fix For: 1.40.0
>
> Attachments: OAK-9024.patch
>
>
> From the manifest:
> {{org.slf4j.impl;version="[1.6,2)"}}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OAK-6892) Query: ability to "nicely" traverse

[Andrei Dulceanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-6892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-6892:
-
Fix Version/s: (was: 1.38.0)
   1.40.0

> Query: ability to "nicely" traverse
> ---
>
> Key: OAK-6892
> URL: https://issues.apache.org/jira/browse/OAK-6892
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: query
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Major
> Fix For: 1.40.0
>
>
> Currently, queries that traverse many nodes log a warning, or can even fail 
> (if configured). This is to ensure system resources are not blocked (CPU, 
> I/O, memory).
> But there are cases where it doesn't make sense to create an index, but 
> traverse (a certain path structure, or sometimes even the whole repository). 
> For example, finding a text with "like '%xxx%'". The problem isn't that it's 
> slow; the problem is that it's blocking / slowing down other users. Another 
> example is during migration, where the alternative is to create an index 
> (which also traverses the repository).
> One option is to allow such queries to run, but throttle them. We could add 
> the hint {{option(traversal throttle)}} to do that. Throttle means: don't use 
> up all I/O, but yield to other tasks depending on config settings (during 
> migration, yield is not needed). As a rule of thumb, the longer the query 
> runs, the more should it yield (up to some value).
> It would be good to allow stopping such queries, and get progress 
> information. The easiest solution might be over JMX, and a more advanced 
> solution is using new API (like, using an interface QueryTraversalObserver, 
> and have our QueryResult implement that interface).



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OAK-3380) Property index pruning should happen asynchronously

[Andrei Dulceanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-3380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-3380:
-
Fix Version/s: (was: 1.38.0)
   1.40.0

> Property index pruning should happen asynchronously
> ---
>
> Key: OAK-3380
> URL: https://issues.apache.org/jira/browse/OAK-3380
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: property-index
>Affects Versions: 1.3.5
>Reporter: Vikas Saurabh
>Priority: Minor
>  Labels: resilience
> Fix For: 1.40.0
>
>
> Following up on this (a relatively old) thread \[1], we should do pruning of 
> property index structure asynchronously. The thread was never concluded.. 
> here are a couple of ideas picked from the thread:
> * Move pruning to an async thread
> * Throttle pruning i.e. prune only once in a while
> ** I'm not sure how that would work though -- an unpruned part would remain 
> as is until another index happens on that path.
> Once we can move pruning to some async thread (reducing concurrent updates), 
> OAK-2673 + OAK-2929 can take care of add-add conflicts.
> 
> h6. Why is this an issue despite merge retries taking care of it?
> A couple of cases which have concurrent updates hitting merge conflicts in 
> our product (Adobe AEM):
> * Some index are very volatile (in the sense that indexed property switches 
> its values very quickly) e.g. sling job status, AEM workflow status.
> * Multiple threads take care of jobs. Although sling maintains a bucketed 
> structure for job storage to reduce conflicts... but inside index tree the 
> bucket structure, at times, gets pruned and needs to be created in the next 
> job status change
> While retries do take care of these conflict a lot of times and even when 
> they don't, AEM workflows has it's own retry to work around. But, retrying, 
> IMHO, is just a waste of time -- more importantly in paths where application 
> doesn't really have a control.
> h6. Would this add to cost of traversing index structure?
> Yes, there'd be some left over paths in index structure between asynchronous 
> prunes. But, I think the cost of such wasted traversals would be covered up 
> with time saved in avoiding the concurrent update conflict.
> 
> (cc [~tmueller], [~mreutegg], [~alex.parvulescu], [~chetanm])
> \[1]: 
> http://mail-archives.apache.org/mod_mbox/jackrabbit-oak-dev/201506.mbox/%3ccadichf66u2vh-hlrjunansytxfidj2mt3vktr4ybkngpzy9...@mail.gmail.com%3E



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OAK-7504) Include dynamic commit information in the persisted repository data

[Andrei Dulceanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-7504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-7504:
-
Fix Version/s: (was: 1.38.0)
   1.40.0

> Include dynamic commit information in the persisted repository data
> ---
>
> Key: OAK-7504
> URL: https://issues.apache.org/jira/browse/OAK-7504
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: segment-tar
>Reporter: Francesco Mari
>Priority: Minor
> Fix For: 1.40.0
>
>
> The data in the Segment Store doesn't provide any information about the 
> dynamic behaviour of the system. For example, who performed the commit? How 
> many commits were performed from the same committer?
> In order to simplify debugging the dynamic behaviour of a system, it should 
> be possible to store metadata about the commit in the super-root generated by 
> that commit. For example, the following information might be attached to the 
> super-root:
> * The name of the thread performing the commit. This solution might prove 
> expensive in terms of consumed disk space, but would be the most precise tool 
> to identify the author of a commit.
> * A hash of the thread name. If storing thread names proves expensive, a hash 
> of the thread name can be stored instead. This doesn't allow to exactly 
> identify the author of the commit, but would allow us to correlated different 
> commits as performed by the same thread.
> * Both the thread name and its hash, with the thread name stored only every 
> Nth commit. This solution is not as precise as storing the thread name for 
> every commit but, if there is a frequent committer, its thread name will be 
> more likely to be sampled, thus providing a precise identity to a thread name 
> hash.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OAK-8859) RDB*Store: update Oracle JDBC dependency to 19.3.0.0

[Andrei Dulceanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-8859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-8859:
-
Fix Version/s: (was: 1.38.0)
   1.40.0

> RDB*Store: update Oracle JDBC dependency to 19.3.0.0
> 
>
> Key: OAK-8859
> URL: https://issues.apache.org/jira/browse/OAK-8859
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: parent
>Reporter: Julian Reschke
>Priority: Minor
> Fix For: 1.40.0
>
> Attachments: OAK-8859.diff
>
>
> See 
> .



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OAK-4581) Persistent local journal for more reliable event generation

[Andrei Dulceanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-4581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-4581:
-
Fix Version/s: (was: 1.38.0)
   1.40.0

> Persistent local journal for more reliable event generation
> ---
>
> Key: OAK-4581
> URL: https://issues.apache.org/jira/browse/OAK-4581
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: core
>Reporter: Chetan Mehrotra
>Priority: Major
>  Labels: observation
> Fix For: 1.40.0
>
> Attachments: OAK-4581.v0.patch
>
>
> As discussed in OAK-2683 "hitting the observation queue limit" has multiple 
> drawbacks. Quite a bit of work is done to make diff generation faster. 
> However there are still chances of event queue getting filled up. 
> This issue is meant to implement a persistent event journal. Idea here being
> # NodeStore would push the diff into a persistent store via a synchronous 
> observer
> # Observors which are meant to handle such events in async way (by virtue of 
> being wrapped in BackgroundObserver) would instead pull the events from this 
> persisted journal
> h3. A - What is persisted
> h4. 1 - Serialized Root States and CommitInfo
> In this approach we just persist the root states in serialized form. 
> * DocumentNodeStore - This means storing the root revision vector
> * SegmentNodeStore - {color:red}Q1 - What does serialized form of 
> SegmentNodeStore root state looks like{color} - Possible the RecordId of 
> "root" state
> Note that with OAK-4528 DocumentNodeStore can rely on persisted remote 
> journal to determine the affected paths. Which reduces the need for 
> persisting complete diff locally.
> Event generation logic would then "deserialize" the persisted root states and 
> then generate the diff as currently done via NodeState comparison
> h4. 2 - Serialized commit diff and CommitInfo
> In this approach we can save the diff in JSOP form. The diff only contains 
> information about affected path. Similar to what is current being stored in 
> DocumentNodeStore journal
> h4. CommitInfo
> The commit info would also need to be serialized. So it needs to be ensure 
> whatever is stored there can be serialized or re calculated
> h3. B - How it is persisted
> h4. 1 - Use a secondary segment NodeStore
> OAK-4180 makes use of SegmentNodeStore as a secondary store for caching. 
> [~mreutegg] suggested that for persisted local journal we can also utilize a 
> SegmentNodeStore instance. Care needs to be taken for compaction. Either via 
> generation approach or relying on online compaction
> h4. 2- Make use of write ahead log implementations
> [~ianeboston] suggested that we can make use of some write ahead log 
> implementation like [1], [2] or [3]
> h3. C - How changes get pulled
> Some points to consider for event generation logic
> # Would need a way to keep pointers to journal entry on per listener basis. 
> This would allow each Listener to "pull" content changes and generate diff as 
> per its speed and keeping in memory overhead low
> # The journal should survive restarts
> [1] http://www.mapdb.org/javadoc/latest/mapdb/org/mapdb/WriteAheadLog.html
> [2] 
> https://github.com/apache/activemq/tree/master/activemq-kahadb-store/src/main/java/org/apache/activemq/store/kahadb/disk/journal
> [3] 
> https://github.com/elastic/elasticsearch/tree/master/core/src/main/java/org/elasticsearch/index/translog



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OAK-6973) Define public/internal packages

[Andrei Dulceanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-6973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-6973:
-
Fix Version/s: (was: 1.38.0)
   1.40.0

> Define public/internal packages
> ---
>
> Key: OAK-6973
> URL: https://issues.apache.org/jira/browse/OAK-6973
> Project: Jackrabbit Oak
>  Issue Type: Task
>Reporter: Marcel Reutegger
>Priority: Major
> Fix For: 1.40.0
>
>
> As part of the Oak modularization packages previously exported without a 
> version will at some point have to adhere to proper semantic versioning. See 
> also OAK-3919 and its sub-tasks.
> Since some of those packages are not meant to be used outside of Oak, there 
> should be a mechanism to define which exported packages are public and which 
> are considered internal. While semantic versioning rules apply to both 
> categories, we may want to provide different guarantees/guidance to consumers 
> of those packages. E.g. increasing the major version of a package used only 
> by Oak has less impact compared to a major version increase of a 'public' 
> package used by many applications.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OAK-7098) Refactor common logic between IndexUpdate and DocumentStoreIndexer

[Andrei Dulceanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-7098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-7098:
-
Fix Version/s: (was: 1.38.0)
   1.40.0

> Refactor common logic between IndexUpdate and DocumentStoreIndexer
> --
>
> Key: OAK-7098
> URL: https://issues.apache.org/jira/browse/OAK-7098
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: indexing, run
>Reporter: Chetan Mehrotra
>Priority: Major
> Fix For: 1.40.0
>
>
> DocumentStoreIndexer implements an alternative way of indexing which differs 
> from diff based indexing done by IndexUpdate. However some part of logic is 
> commong
> We should refactor them and abstract them out so both can share same logic



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OAK-5506) reject item names with unpaired surrogates early

[Andrei Dulceanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-5506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-5506:
-
Fix Version/s: (was: 1.38.0)
   1.40.0

> reject item names with unpaired surrogates early
> 
>
> Key: OAK-5506
> URL: https://issues.apache.org/jira/browse/OAK-5506
> Project: Jackrabbit Oak
>  Issue Type: Wish
>  Components: core, jcr, segment-tar
>Affects Versions: 1.5.18
>Reporter: Julian Reschke
>Priority: Minor
>  Labels: resilience
> Fix For: 1.40.0
>
> Attachments: OAK-5506-01.patch, OAK-5506-02.patch, OAK-5506-4.diff, 
> OAK-5506-bench.diff, OAK-5506-jcr-level.diff, OAK-5506-name-conversion.diff, 
> OAK-5506-segment.diff, OAK-5506-segment2.diff, OAK-5506-segment3.diff, 
> OAK-5506.diff, ValidNamesTest.java
>
>
> Apparently, the following node name is accepted:
>{{"foo\ud800"}}
> but a subsequent {{getPath()}} call fails:
> {noformat}
> javax.jcr.InvalidItemStateException: This item [/test_node/foo?] does not 
> exist anymore
> at 
> org.apache.jackrabbit.oak.jcr.delegate.ItemDelegate.checkAlive(ItemDelegate.java:86)
> at 
> org.apache.jackrabbit.oak.jcr.session.operation.ItemOperation.checkPreconditions(ItemOperation.java:34)
> at 
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.prePerform(SessionDelegate.java:615)
> at 
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.perform(SessionDelegate.java:205)
> at 
> org.apache.jackrabbit.oak.jcr.session.ItemImpl.perform(ItemImpl.java:112)
> at 
> org.apache.jackrabbit.oak.jcr.session.ItemImpl.getPath(ItemImpl.java:140)
> at 
> org.apache.jackrabbit.oak.jcr.session.NodeImpl.getPath(NodeImpl.java:106)
> at 
> org.apache.jackrabbit.oak.jcr.ValidNamesTest.nameTest(ValidNamesTest.java:271)
> at 
> org.apache.jackrabbit.oak.jcr.ValidNamesTest.testUnpairedSurrogate(ValidNamesTest.java:259)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source){noformat}
> (test case follows)



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OAK-6769) Convert oak-search-mt to OSGi R6 annotations

[Andrei Dulceanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-6769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-6769:
-
Fix Version/s: (was: 1.38.0)
   1.40.0

> Convert oak-search-mt to OSGi R6 annotations
> 
>
> Key: OAK-6769
> URL: https://issues.apache.org/jira/browse/OAK-6769
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>Reporter: Robert Munteanu
>Priority: Major
> Fix For: 1.40.0
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OAK-6767) Remove felix SCR annotation support from parent pom

[Andrei Dulceanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-6767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-6767:
-
Fix Version/s: (was: 1.38.0)
   1.40.0

> Remove felix SCR annotation support from parent pom
> ---
>
> Key: OAK-6767
> URL: https://issues.apache.org/jira/browse/OAK-6767
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: parent
>Reporter: Robert Munteanu
>Priority: Major
> Fix For: 1.40.0
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OAK-7922) Improve the operations and the reporting of the check command

[Andrei Dulceanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-7922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-7922:
-
Fix Version/s: (was: 1.38.0)
   1.40.0

> Improve the operations and the reporting of the check command
> -
>
> Key: OAK-7922
> URL: https://issues.apache.org/jira/browse/OAK-7922
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: segment-tar
>Reporter: Francesco Mari
>Priority: Major
> Fix For: 1.40.0
>
> Attachments: OAK-7922-01.patch
>
>
> The check command allows a user to check for both the head and the 
> checkpoints. At the end of the execution the command outputs the consistent 
> revisions for the head and the individual checkpoints, if any is found. 
> Moreover, it prints an overall good revision. The consistent revisions for 
> the head and the checkpoints could all be different. If both the head and all 
> the checkpoints are assigned to a consistent revision, the overall good 
> revision is the oldest of those revisions.
> I wonder how useful all of this information is to a user of the command:
>  - I might have a revision where a checkpoint is consistent, but the head is 
> not. In this case, I don't want to revert to that revision because my system 
> will probably be unstable due to the inconsistent head.
>  - The overall good revision might still be partially inconsistent due to the 
> way the command short-circuits the consistency check on the head and the 
> checkpoints. If I revert to the overall good revision, the head might still 
> be inconsistent or one of the checkpoints might be missing.
> I propose to remove the {{\--checkpoints}} and the {{\--head}} flags and 
> define the behaviour of the command as follows.
>  - The check command checks one super-root at a time in its entirety (both 
> head and referenced checkpoints).
>  - The command exits as soon as a super-root is found where both the head and 
> all the checkpoints are consistent.
>  - While searching, the command might find a super-root with a consistent 
> head but one or more inconsistent checkpoint. In this case, the first of such 
> revisions is printed, specifying which checkpoints are inconsistent.
>  - The user might specify a {{--no-checkpoints}} flag to skip checking the 
> checkpoints in the steps above.
> The optimisations currently implemented by the check command can be 
> maintained. We don't need to fully traverse the head or the checkpoints if a 
> well-known corrupted path is still corrupted in the current iteration. The 
> approach proposed above enables additional optimisations:
>  - Since checkpoints are immutable, the command doesn't need to traverse a 
> checkpoint that was inspected before. This is true regardless of the 
> consistency of the checkpoint.
>  - If a super-root includes a checkpoint that was previously determined 
> corrupted, the command can skip that super-root without further inspection.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OAK-5661) Make NRT indexing resilient against unbounded growth

[Andrei Dulceanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-5661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-5661:
-
Fix Version/s: (was: 1.38.0)
   1.40.0

> Make NRT indexing resilient against unbounded growth
> 
>
> Key: OAK-5661
> URL: https://issues.apache.org/jira/browse/OAK-5661
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: lucene
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Major
> Fix For: 1.40.0
>
>
> NRT Indexes for volatile indexes [1] can grow large if async index update 
> faces issues. Like if it gets stuck for days or due to some bug index do not 
> get updates like in OAK-5649 then the sizes can grow very large.
> For such cases we should add some checks in logic where system can ensure 
> that some cleanup is performed or writes to indexes are stopped. Also such a 
> situation should be flagged 
> [1] Indexes which see lots of addition and deletions. So effective indexing 
> size is smaller however if deletions are not applied (as is the case with 
> NRT) such indexes can grow large



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OAK-5897) Optimize like constraint support in Property Indexes

[Andrei Dulceanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-5897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-5897:
-
Fix Version/s: (was: 1.38.0)
   1.40.0

> Optimize like constraint support in Property Indexes
> 
>
> Key: OAK-5897
> URL: https://issues.apache.org/jira/browse/OAK-5897
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: property-index
>Reporter: Chetan Mehrotra
>Assignee: Thomas Mueller
>Priority: Major
> Fix For: 1.40.0
>
>
> Consider a query
> {noformat}
>  /jcr:root/content//element(*, nt:unstructured)[jcr:like(@resource, 
> '/content/foo/bar%')]
> {noformat}
> This currently gets translated into a range property restriction 
> {noformat}
>  property=[resource=[[/content/foo/bar.., ../content/foo/bas]]]
> {noformat}
> For such a query property index currently returns all nodes having "resource" 
> property i.e. all index data. This can be optimized to return only those 
> nodes where indexed value qualifies the range property restriction



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OAK-6757) Convert oak-auth-ldap to OSGi R6 annotations

[Andrei Dulceanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-6757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-6757:
-
Fix Version/s: (was: 1.38.0)
   1.40.0

> Convert oak-auth-ldap to OSGi R6 annotations
> 
>
> Key: OAK-6757
> URL: https://issues.apache.org/jira/browse/OAK-6757
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: auth-ldap
>Reporter: Robert Munteanu
>Priority: Major
> Fix For: 1.40.0
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OAK-8413) Use the new Azure SDK in the Azure Segment Store

[Andrei Dulceanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-8413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-8413:
-
Fix Version/s: (was: 1.38.0)
   1.40.0

> Use the new Azure SDK in the Azure Segment Store
> 
>
> Key: OAK-8413
> URL: https://issues.apache.org/jira/browse/OAK-8413
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: segment-azure
>Reporter: Tomek Rękawek
>Assignee: Andrei Dulceanu
>Priority: Major
> Fix For: 1.40.0
>
>
> We should update the oak-segment-azure to use the most recent Azure SDK 
> version, to keep it compatible with the oak-blob-cloud-azure (see OAK-8105):
> {code}
> 
> com.microsoft.azure
> azure-storage-blob
> 11.0.1
> 
> {code}
> //cc: [~mattvryan]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OAK-9240) oak-benchmarks jar should be deployed to maven-central

[Andrei Dulceanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-9240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-9240:
-
Fix Version/s: (was: 1.38.0)
   1.40.0

> oak-benchmarks jar should be deployed to maven-central
> --
>
> Key: OAK-9240
> URL: https://issues.apache.org/jira/browse/OAK-9240
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: benchmarks
>Affects Versions: 1.34.0
>Reporter: Aravindo Wingeier
>Assignee: Andrei Dulceanu
>Priority: Trivial
> Fix For: 1.40.0
>
> Attachments: Do_not_skip_deployment_for_oak-benchmarks.patch
>
>
> While [oak-run jar is deployed to maven 
> central|https://repo1.maven.org/maven2/org/apache/jackrabbit/oak-run/1.34.0/],
>  oak-benchmarks is missing. 
>  This is probably due to the property in `oak-benchmarks/pom.xml`:
> {code}
> 
> true
> 
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OAK-7106) Index Tooling for Oak 1.10

[Andrei Dulceanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-7106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-7106:
-
Fix Version/s: (was: 1.38.0)
   1.40.0

> Index Tooling for Oak 1.10
> --
>
> Key: OAK-7106
> URL: https://issues.apache.org/jira/browse/OAK-7106
> Project: Jackrabbit Oak
>  Issue Type: Epic
>  Components: indexing, run
>Reporter: Chetan Mehrotra
>Priority: Major
> Fix For: 1.40.0
>
>
> Epic to track tooling work for Oak 1.10 release



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OAK-6766) Convert oak-lucene to OSGi R6 annotations

[Andrei Dulceanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-6766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-6766:
-
Fix Version/s: (was: 1.38.0)
   1.40.0

> Convert oak-lucene to OSGi R6 annotations
> -
>
> Key: OAK-6766
> URL: https://issues.apache.org/jira/browse/OAK-6766
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: lucene
>Reporter: Robert Munteanu
>Priority: Major
> Fix For: 1.40.0
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OAK-6501) Support adding or updating index definitions via oak-run: JSON data format

[Andrei Dulceanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-6501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-6501:
-
Fix Version/s: (was: 1.38.0)
   1.40.0

> Support adding or updating index definitions via oak-run: JSON data format
> --
>
> Key: OAK-6501
> URL: https://issues.apache.org/jira/browse/OAK-6501
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Major
> Fix For: 1.40.0
>
>
> In OAK-6471 we have support for index definitions via JSON.
> I'm not happy with the escaping (OAK-6476) ("If the string starts with 
> namespace..."), I think it's a bit dangerous. Need to investigate whether 
> this prevents importing index definitions exported via JSON 
> (localhost:/oak:index/lucene.tidy.-1.json).



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OAK-6762) Convert oak-blob to OSGi R6 annotations

[Andrei Dulceanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-6762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-6762:
-
Fix Version/s: (was: 1.38.0)
   1.40.0

> Convert oak-blob to OSGi R6 annotations
> ---
>
> Key: OAK-6762
> URL: https://issues.apache.org/jira/browse/OAK-6762
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: blob
>Reporter: Robert Munteanu
>Priority: Major
> Fix For: 1.40.0
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OAK-3919) Properly manage APIs / SPIs intended for public consumption

[Andrei Dulceanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-3919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-3919:
-
Fix Version/s: (was: 1.38.0)
   1.40.0

> Properly manage APIs / SPIs intended for public consumption
> ---
>
> Key: OAK-3919
> URL: https://issues.apache.org/jira/browse/OAK-3919
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: core
>Reporter: Michael Dürig
>Priority: Major
>  Labels: modularization, technical_debt
> Fix For: 1.40.0
>
>
> This is a follow up to OAK-3842, which removed package export declarations 
> for all packages that we either do not want to be used outside of Oak or that 
> are not stable enough yet. 
> This issue is to identify those APIs and SPIs of Oak that we actually *want* 
> to export and to refactor those such we *can* export them. 
> Candidates that are currently used from upstream projects I know of are:
> {code}
>   org.apache.jackrabbit.oak.plugins.observation
>   org.apache.jackrabbit.oak.spi.commit
>   org.apache.jackrabbit.oak.spi.state
>   org.apache.jackrabbit.oak.commons
>   org.apache.jackrabbit.oak.plugins.index.lucene
> {code}
> I suggest to create subtask for those we want to go forward with.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OAK-8288) fix javadoc:javadoc for jdk >= 13

[Andrei Dulceanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-8288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-8288:
-
Fix Version/s: (was: 1.38.0)
   1.40.0

> fix javadoc:javadoc for jdk >= 13
> -
>
> Key: OAK-8288
> URL: https://issues.apache.org/jira/browse/OAK-8288
> Project: Jackrabbit Oak
>  Issue Type: Bug
>Reporter: Julian Reschke
>Priority: Minor
> Fix For: 1.40.0
>
> Attachments: JavaDocHtmlHeaderTest.java
>
>
> Javadoc in JDK 13 makes additional HTML validity checks:
>  * nesting of headlines ( after  is an error)
>  * empty  tags



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OAK-6515) Decouple indexing and upload to datastore

[Andrei Dulceanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-6515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-6515:
-
Fix Version/s: (was: 1.38.0)
   1.40.0

> Decouple indexing and upload to datastore
> -
>
> Key: OAK-6515
> URL: https://issues.apache.org/jira/browse/OAK-6515
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: indexing, lucene, query
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Minor
> Fix For: 1.40.0
>
>
> Currently the default async index delay is 5 seconds. Using a larger delay 
> (e.g. 15 seconds) reduces index related growth, however diffing is delayed 15 
> seconds, which can reduce indexing performance. 
> One option (which might require bigger changes) is to index every 5 seconds, 
> and store the index every 5 seconds in the local directory, but only write to 
> the datastore / nodestore every 3rd time (that is, every 15 seconds).
> So that other cluster nodes will only see the index update every 15 seconds. 
> The diffing is done every 5 seconds, and the local index could be used every 
> 5 or every 15 seconds.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OAK-3236) integration test that simulates influence of clock drift

[Andrei Dulceanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-3236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-3236:
-
Fix Version/s: (was: 1.38.0)
   1.40.0

> integration test that simulates influence of clock drift
> 
>
> Key: OAK-3236
> URL: https://issues.apache.org/jira/browse/OAK-3236
> Project: Jackrabbit Oak
>  Issue Type: Test
>  Components: core
>Affects Versions: 1.3.4
>Reporter: Stefan Egli
>Priority: Major
> Fix For: 1.40.0
>
>
> Spin-off of OAK-2739 [of this 
> comment|https://issues.apache.org/jira/browse/OAK-2739?focusedCommentId=14693398=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14693398]
>  - ie there should be an integration test that show cases the issues with 
> clock drift and why it is a good idea to have a lease-check (that refuses to 
> let the document store be used any further once the lease times out locally)



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OAK-7043) Collect SegmentStore stats as part of status zip

[Andrei Dulceanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-7043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-7043:
-
Fix Version/s: (was: 1.38.0)
   1.40.0

> Collect SegmentStore stats as part of status zip
> 
>
> Key: OAK-7043
> URL: https://issues.apache.org/jira/browse/OAK-7043
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: segment-tar
>Reporter: Chetan Mehrotra
>Priority: Major
>  Labels: monitoring, production
> Fix For: 1.40.0
>
>
> Many times while investigating issue we request customer to provide to size 
> of segmentstore and at times list of segmentstore directory. It would be 
> useful if there is an InventoryPrinter for SegmentStore which can include
> * Size of segment store 
> * Listing of segment store directory
> * Possibly tail of journal.log
> * Possibly some stats/info from index files stored in tar files



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OAK-7151) Support indexed based excerpts on properties

[Andrei Dulceanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-7151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-7151:
-
Fix Version/s: (was: 1.38.0)
   1.40.0

> Support indexed based excerpts on properties
> 
>
> Key: OAK-7151
> URL: https://issues.apache.org/jira/browse/OAK-7151
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Major
> Fix For: 1.40.0
>
> Attachments: OAK-7151.patch, OAK-7151.xpath-new-syntax.patch, 
> OAK-7151.xpath.patch
>
>
> As discovered in OAK-4401 we fallback to {{SimpleExcerptProvider}} when 
> requesting excerpts for properties.
> The issue as highlighted in [~teofili]'s comment \[0] is that we at time of 
> query we don't have information about which all columns/fields would be 
> required for excerpts.
> A possible approach is that the query specified explicitly which columns 
> would be required in facets (of course, node level excerpt would still be 
> supported). This issue is to track that improvement.
> Note: this is *not* a substitute for OAK-4401 which is about doing saner 
> highlighting when {{SimpleExcerptProvider}} comes into play e.g. despite this 
> issue excerpt for non-stored fields (properties which aren't configured with 
> {{useInExcerpt}} in the index definition}, we'd need to fallback to 
> {{SimpleExcerptProvider}}.
> /[~tmueller]
> \[0]: 
> https://issues.apache.org/jira/browse/OAK-4401?focusedCommentId=15299857=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15299857



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OAK-6303) Cache in CachingBlobStore might grow beyond configured limit

[Andrei Dulceanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-6303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-6303:
-
Fix Version/s: (was: 1.38.0)
   1.40.0

> Cache in CachingBlobStore might grow beyond configured limit
> 
>
> Key: OAK-6303
> URL: https://issues.apache.org/jira/browse/OAK-6303
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: blob, core
>Reporter: Julian Reschke
>Priority: Major
> Fix For: 1.40.0
>
> Attachments: OAK-6303-test.diff, OAK-6303.diff
>
>
> It appears that depending on actual cache entry sizes, the {{CacheLIRS}} 
> might grow beyond the configured limit.
> For {{RDBBlobStore}}, the limit is currently configured to 16MB, yet storing 
> random 2M entries appears to fill the cache with 64MB of data (according to 
> it's own stats).
> The attached test case reproduces this.
> (it seems this is caused by the fact that each of the 16 segments of the 
> cache can hold 2 entries, no matter how big they are...)



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OAK-7212) Document the document order traversal option

[Andrei Dulceanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-7212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-7212:
-
Fix Version/s: (was: 1.38.0)
   1.40.0

> Document the document order traversal option
> 
>
> Key: OAK-7212
> URL: https://issues.apache.org/jira/browse/OAK-7212
> Project: Jackrabbit Oak
>  Issue Type: Documentation
>  Components: doc, run
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Major
> Fix For: 1.40.0
>
>
> Document the doc-order-traversal option introduced with OAK-6353



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OAK-1150) NodeType index: don't index all primary and mixin types

[Andrei Dulceanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-1150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-1150:
-
Fix Version/s: (was: 1.38.0)
   1.40.0

> NodeType index: don't index all primary and mixin types
> ---
>
> Key: OAK-1150
> URL: https://issues.apache.org/jira/browse/OAK-1150
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: property-index
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Major
> Fix For: 1.40.0
>
>
> Currently, the nodetype index indexes all primary types and mixin types 
> (including nt:base I think).
> This results in many nodes in this index, which unnecessarily increases the 
> repository size, but doesn't really help executing queries (running a query 
> to get all nt:base nodes doesn't benefit much from using the nodetype index).
> It should also help reduce writes in updating the index, for example for 
> OAK-1099



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OAK-7846) Add a tool to export the tree pointed to by a node record

[Andrei Dulceanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-7846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-7846:
-
Fix Version/s: (was: 1.38.0)
   1.40.0

> Add a tool to export the tree pointed to by a node record
> -
>
> Key: OAK-7846
> URL: https://issues.apache.org/jira/browse/OAK-7846
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: segment-tar
>Affects Versions: 1.10.0
>Reporter: Francesco Mari
>Priority: Major
> Fix For: 1.40.0
>
> Attachments: OAK-7846-01.patch, OAK-7846-02.patch
>
>
> oak-segment-tar should have a tool that allows exporting a tree pointed to by 
> a node record. The tool must be written in a way that plays along with 
> existing Oak tools (see OAK-7834) and conventional UNIX ones.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OAK-5927) Load excerpt lazily

[Andrei Dulceanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-5927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-5927:
-
Fix Version/s: (was: 1.38.0)
   1.40.0

> Load excerpt lazily
> ---
>
> Key: OAK-5927
> URL: https://issues.apache.org/jira/browse/OAK-5927
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: lucene
>Reporter: Chetan Mehrotra
>Priority: Major
>  Labels: performance
> Fix For: 1.40.0
>
>
> Currently LucenePropertyIndex loads the excerpt eagerly in batch as part of 
> loadDocs call. The load docs batch size doubles starting from 50 (max 100k) 
> as more data is read. 
> We should look into ways to make the excerpt loaded lazily as and when caller 
> ask for excerpt.
> Note that currently the excerpt are only loaded when query request for 
> excerpt i.e. there is a not null property restriction for {{rep:excerpt}}. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OAK-6577) Determine the approach for reindexing in case of CompositeNodeStore setups

[Andrei Dulceanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-6577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-6577:
-
Fix Version/s: (was: 1.38.0)
   1.40.0

> Determine the approach for reindexing in case of CompositeNodeStore setups
> --
>
> Key: OAK-6577
> URL: https://issues.apache.org/jira/browse/OAK-6577
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: composite, indexing
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Major
> Fix For: 1.40.0
>
>
> Current index tooling is designed to work with a single NodeStore setups. We 
> should determine how reindexing should be done for CompositeNodeStore setup 
> specially where one of the mount is private and read only



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OAK-6914) Improve indexing progress estimates with multiple includes

[Andrei Dulceanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-6914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-6914:
-
Fix Version/s: (was: 1.38.0)
   1.40.0

> Improve indexing progress estimates with multiple includes
> --
>
> Key: OAK-6914
> URL: https://issues.apache.org/jira/browse/OAK-6914
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: indexing
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: 1.40.0
>
>
> With OAK-5970 support was added for providing ETA as indexing progresses. 
> However as discussed in the issue this estimate might not be good if indexes 
> have multiple include and excludes
> Purpose of this task is to look for ways to improve it



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OAK-7261) DocumentStore: inconsistent behaviour for invalid Strings as document ID

[Andrei Dulceanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-7261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-7261:
-
Fix Version/s: (was: 1.38.0)
   1.40.0

> DocumentStore: inconsistent behaviour for invalid Strings as document ID
> 
>
> Key: OAK-7261
> URL: https://issues.apache.org/jira/browse/OAK-7261
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: documentmk, mongomk, rdbmk
>Reporter: Julian Reschke
>Priority: Major
> Fix For: 1.40.0
>
>
> - H2DB and Derby roundtrip any string
>  - PostgreSQL rejects the invalid string early
>  - DB2 and Oracle fail the same way as segment store (they persist the 
> replacement character) (see OAK-5506)
>  - MySQL and SQLServer fail the same way as DB2 and Oracle, but here it's the 
> RDBDocumentStore's fault, because the ID column is binary, and we transform 
> to byte sequences ourselves
>  - Mongo claims it saved the document, but upon lookup, returns something 
> with a different ID
> Note that due to how RDB reads work, the returned document has the ID that 
> was requested, not what the DB actually contains.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OAK-7116) Use JMX mode to reindex on SegmentNodeStore without requiring manual steps

[Andrei Dulceanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-7116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-7116:
-
Fix Version/s: (was: 1.38.0)
   1.40.0

> Use JMX mode to reindex on SegmentNodeStore without requiring manual steps
> --
>
> Key: OAK-7116
> URL: https://issues.apache.org/jira/browse/OAK-7116
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: run
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Major
> Fix For: 1.40.0
>
>
> oak-run indexing for SegmentNodeStore currently require following steps while 
> performing indexing against a repository which is in use [1]
> # Create checkpoint via MBean and pass it as part of cli args
> # Perform actual indexing with read only access to repo
> # Import the index via MBean operation 
> As per current documented steps #1 and #3 are manual. This can potentially be 
> simplified by directly using JMX operation from within oak-run as currently 
> for accessing SegmentNodeStore oak-run needs to run on same host as actual 
> application
> *JMX Access*
> JMX access can be done via following ways
> # Application using Oak has JMX remote 
> ## Enabled and same info provided as cli args
> ## Not enabled - In such a case we can rely on 
> ### pid and [local 
> connection|https://stackoverflow.com/questions/13252914/how-to-connect-to-a-local-jmx-server-by-knowing-the-process-id]
>  or [attach|https://github.com/nickman/jmxlocal]
> ### Or query all running java prcess jmx and check if SegmentNodeStore repo 
> path is same as one provided in cli
> # Application using OAk
> *Proposed Approach*
> # Establish the JMX connection
> # Create checkpoint using the JMX connection programatically
> # Perform indexing with read only access
> # Import the index via JMX access
> With this indexing support for SegmentNodeStore would be at par with 
> DocumentNodeStore in terms of ease of use
> [1] https://jackrabbit.apache.org/oak/docs/query/oak-run-indexing.html



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OAK-3141) Oak should warn when too many ordered child nodes

[Andrei Dulceanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-3141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-3141:
-
Fix Version/s: (was: 1.38.0)
   1.40.0

> Oak should warn when too many ordered child nodes
> -
>
> Key: OAK-3141
> URL: https://issues.apache.org/jira/browse/OAK-3141
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 1.0.16
>Reporter: Jörg Hoh
>Assignee: Thomas Mueller
>Priority: Major
> Fix For: 1.40.0
>
>
> When working with the RDBMK we came into situations, that large documents did 
> not fit into the provided db columns, there was an overflow, which caused oak 
> not to persist the change. We fixed it by increasing the size of the column.
> But it would be nice if Oak could warn if a document exceeds a certain size 
> (for example 2 megabytes); because this warning indicates, that on a JCR 
> level there might be a problematic situation, for example:
> * ordered node with a large list of childnodes
> * or longstanding sessions with lots of changes, which accumulate to large 
> documents.
> It's certainly nice to know if there's a node/document with such a problem, 
> before the exceptions actually happens and an operation breaks.
> This message should be a warning, and should contain the JCR path of the node 
> plus the current size. To avoid that this message is overseen, it would be 
> good if it is written everyonce in a while (every 10 minutes?) if this 
> condition persists.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OAK-5889) Change internal queries to use "option(traversal fail)"

[Andrei Dulceanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-5889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-5889:
-
Fix Version/s: (was: 1.38.0)
   1.40.0

> Change internal queries to use "option(traversal fail)"
> ---
>
> Key: OAK-5889
> URL: https://issues.apache.org/jira/browse/OAK-5889
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: query
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Major
> Fix For: 1.40.0
>
>
> The Oak internal queries that use an index (that is, hopefully all of them) 
> should fail if no index is available. For example, it's better to fail 
> queries that search a node by UUID, if the UUID index is disabled, otherwise 
> for each such query, the complete repository is traversed.
> To do that, "option(traversal fail)" can be appended to the query.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OAK-2777) Minimize the cost calculation for queries using reference restrictions.

[Andrei Dulceanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-2777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-2777:
-
Fix Version/s: (was: 1.38.0)
   1.40.0

> Minimize the cost calculation for queries using reference restrictions.
> ---
>
> Key: OAK-2777
> URL: https://issues.apache.org/jira/browse/OAK-2777
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: core, query
>Affects Versions: 1.1.2, 1.2
>Reporter: Przemyslaw Pakulski
>Assignee: Thomas Mueller
>Priority: Major
>  Labels: performance
> Fix For: 1.40.0
>
> Attachments: oak-2777.patch
>
>
> According to the javadocs (QueryIndex) minimum cost for index is 1. Currently 
> ReferenceIndex returns this minimum value, when it can be used for the query.
> But even then cost for remaining indexes is still calculated. We could skip 
> cost calculation of remaining indexes if we achieved the minimum cost already.
> It will speed up all queries which can leverage the reference Index.
> Example query:
> SELECT * FROM [nt:base] WHERE PROPERTY([rep:members], 'WeakReference') = 
> '345bef9b-ffa1-3e09-85df-1e03cfa0fb37'



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OAK-5159) Killing the process may stop async index update to to 30 minutes, for DocumentStore (MongoDB, RDB)

[Andrei Dulceanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-5159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-5159:
-
Fix Version/s: (was: 1.38.0)
   1.40.0

> Killing the process may stop async index update to to 30 minutes, for 
> DocumentStore (MongoDB, RDB)
> --
>
> Key: OAK-5159
> URL: https://issues.apache.org/jira/browse/OAK-5159
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: indexing
>Reporter: Thomas Mueller
>Priority: Major
>  Labels: resilience
> Fix For: 1.40.0
>
>
> Same as OAK-2108, when using a DocumentStore based repository (MongoDB, 
> RDBMK). This is also a problem in the single-cluster-node case, not just when 
> using multiple cluster node.
> When killing a node that is running the sync index update, then this async 
> index update will not run for up to 15 minutes, because the lease time is set 
> to 15 minutes.
> We could probably use Oak / Sling Discovery to improve the situation.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OAK-9212) AzureArchiveManage.listArchives() should not delete segments

[Andrei Dulceanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-9212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-9212:
-
Fix Version/s: (was: 1.38.0)
   1.40.0

> AzureArchiveManage.listArchives() should not delete segments
> 
>
> Key: OAK-9212
> URL: https://issues.apache.org/jira/browse/OAK-9212
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: segment-azure
>Affects Versions: 1.32.0
>Reporter: Aravindo Wingeier
>Priority: Major
> Fix For: 1.40.0
>
>
> When the segments are listed on an azure blob store and the ".*" blob is 
> missing, it will delete all other segments. This behaviour was introduced 
> with OAK-8566. 
> *Change:* This destructive operation should not happen in method the 
> _AzureArchiveManage.listArchives()_ which indicates a read-only operation. 
> One option is to pull out this functionality and call it somewhere else. 
> *Why is this an issue?*  There is a recovery option in 
> org.apache.jackrabbit.oak.segment.file.tar.TarReader#collectFileEntries which 
> calls org.apache.jackrabbit.oak.segment.file.tar.TarReader#backupSafely. If 
> the recovery is run concurrently with _AzureArchiveManage.listArchives()_ the 
> result can be unexpected. 
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OAK-5860) Compressed segments

[Andrei Dulceanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-5860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-5860:
-
Fix Version/s: (was: 1.38.0)
   1.40.0

> Compressed segments
> ---
>
> Key: OAK-5860
> URL: https://issues.apache.org/jira/browse/OAK-5860
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: segment-tar
>Reporter: Michael Dürig
>Assignee: Andrei Dulceanu
>Priority: Major
>  Labels: scalability
> Fix For: 1.40.0
>
>
> It would be interesting to see the effect of compressing the segments within 
> the tar files with a sufficiently effective and performant compression 
> algorithm:
> * Can we increase overall throughput by trading CPU for IO?
> * Can we scale to bigger repositories (in number of nodes) by squeezing in 
> more segments per MB and thus pushing out onset of thrashing?
> * What would be a good compression algorithm/library?
> * Can/should we make this optional? 
> * Migration and compatibility issues?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OAK-5316) Rewrite JcrPathParser and JcrNameParser with good test coverage

[Andrei Dulceanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-5316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-5316:
-
Fix Version/s: (was: 1.38.0)
   1.40.0

> Rewrite JcrPathParser and JcrNameParser with good test coverage
> ---
>
> Key: OAK-5316
> URL: https://issues.apache.org/jira/browse/OAK-5316
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 1.5.15
>Reporter: Julian Sedding
>Assignee: Thomas Mueller
>Priority: Major
> Fix For: 1.40.0
>
>
> As discussed in OAK-5260 the implementation of the {{JcrPathParser}} and 
> possibly also the {{JcrNameParser}} are not ideal, i.e. there are potentially 
> many bugs hiding in edge-case scenarios. The parsers' test coverage is also 
> lacking, which is problematic as these code paths get executed very 
> frequently.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OAK-7390) QueryResult.getSize() can be slow for many "or" or "union" conditions

[Andrei Dulceanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-7390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-7390:
-
Fix Version/s: (was: 1.38.0)
   1.40.0

> QueryResult.getSize() can be slow for many "or" or "union" conditions
> -
>
> Key: OAK-7390
> URL: https://issues.apache.org/jira/browse/OAK-7390
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: query
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Major
> Fix For: 1.40.0
>
>
> For queries with many union conditions, the "fast" getSize method can 
> actually be slower than iterating over the result. 
> The reason is, the number of index calls grows exponential with regards to 
> number of subqueries: (3x + x^2) / 2, where x is the number of subqueries. 
> For this to have a measurable affect, the number of subqueries needs to be 
> large (more than 100), and the index needs to be slow.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OAK-7425) Add discovery mechanism for tooling implementations

[Andrei Dulceanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-7425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-7425:
-
Fix Version/s: (was: 1.38.0)
   1.40.0

> Add discovery mechanism for tooling implementations
> ---
>
> Key: OAK-7425
> URL: https://issues.apache.org/jira/browse/OAK-7425
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: segment-tar
>Reporter: Francesco Mari
>Priority: Major
>  Labels: technical_debt
> Fix For: 1.40.0
>
> Attachments: 001.patch
>
>
> This issue proposes an idea for discovering implementations of tooling for 
> the Segment Store. Developing a tool for the Segment Store should include the 
> following step.
> * The tool compiles against the {{NodeStore}} API and the API exposed through 
> the oak-segment-tar-tool-api. In particular, the tool uses the 
> {{ToolingSupportFactory}} and related interfaces to instantiate a NodeStore 
> and, optionally, a {{NodeState}} for the proc tree.
> * The tool runs with an implementation-dependent uber-jar in the classpath. 
> The uber-jar includes the {{ToolingSupportFactory}} API, its implementation, 
> and every other class required for the implementation to work. No other JARs 
> is required to use the {{ToolingSupportFactory}} API. The tool uses the 
> Java's {{ServiceLoader}} to instantiate an implementation of 
> {{ToolingSupportFactory}}. The uber-jar is the {{oak-segment-tar-tool}} 
> module.
> The patch falls short of fully implementing the use case because 
> {{oak-segment-tar-tool-api}} is not versioned independently from Oak. This 
> can't happen at the moment because {{oak-store-spi}} and its dependencies are 
> not independently versioned either. The workflow described above could still 
> work, but only because the {{NodeStore}} and {{NodeState}} API are quite 
> stable. A cleaner solution to dependency management is required in the long 
> run.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OAK-4934) Query shapes for JCR Query

[Andrei Dulceanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-4934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-4934:
-
Fix Version/s: (was: 1.38.0)
   1.40.0

> Query shapes for JCR Query
> --
>
> Key: OAK-4934
> URL: https://issues.apache.org/jira/browse/OAK-4934
> Project: Jackrabbit Oak
>  Issue Type: Wish
>  Components: query
>Reporter: Chetan Mehrotra
>Priority: Major
> Fix For: 1.40.0
>
>
> For certain requirements it would be good to have a notion/support to deduce 
> query shape [1]
> {quote}
>  A combination of query predicate, sort, and projection specifications.
> For the query predicate, only the structure of the predicate, including the 
> field names, are significant; the values in the query predicate are 
> insignificant. As such, a query predicate \{ type: 'food' \} is equivalent to 
> the query predicate \{ type: 'utensil' \} for a query shape.
> {quote}
> So transforming that to Oak the shape should represent a JCR-SQL2 query 
> string (xpath query gets transformed to SQL2) which is a *canonical* 
> representation of actual query ignoring the property restriction values. 
> Example we have 2 queries
> * SELECT   * FROM [app:Asset] AS a WHERE  a.[jcr:content/metadata/status] = 
> 'published'
> * SELECT   * FROM [app:Asset] AS a WHERE  a.[jcr:content/metadata/status] = 
> 'disabled'
> The query shape would be 
> SELECT * FROM [app:Asset] AS a WHERE  a.[jcr:content/metadata/status] = 'A'. 
> The plan for query having given shape would remain same irrespective of value 
> of property restrictions. Path restriction can cause some difference though
> The shape can then be used for
> * Stats Collection - Currently stats collection gets overflown if same query 
> with different value gets invoked
> * Allow configuring hints - See support in Mongo [2] for an example. One 
> specify via config that for a query of such and such shape this index should 
> be used
> * Less noisy diagnostics - If a query gets invoked with bad plan the QE can 
> log the warning once instead of logging it for each query invocation 
> involving different values.
> [1] https://docs.mongodb.com/manual/reference/glossary/#term-query-shape
> [2] https://docs.mongodb.com/manual/reference/command/planCacheSetFilter/



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OAK-3598) Export cache related classes for usage in other oak bundle

[Andrei Dulceanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-3598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-3598:
-
Fix Version/s: (was: 1.38.0)
   1.40.0

> Export cache related classes for usage in other oak bundle
> --
>
> Key: OAK-3598
> URL: https://issues.apache.org/jira/browse/OAK-3598
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: cache
>Reporter: Chetan Mehrotra
>Priority: Major
>  Labels: tech-debt
> Fix For: 1.40.0
>
>
> For OAK-3092 oak-lucene would need to access classes from 
> {{org.apache.jackrabbit.oak.cache}} package. For now its limited to 
> {{CacheStats}} to expose the cache related statistics.
> This task is meant to determine steps needed to export the package 
> * Update the pom.xml to export the package
> * Review current set of classes to see if they need to be reviewed



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OAK-5924) Prevent long running query from delaying refresh of index

[Andrei Dulceanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-5924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-5924:
-
Fix Version/s: (was: 1.38.0)
   1.40.0

> Prevent long running query from delaying refresh of index
> -
>
> Key: OAK-5924
> URL: https://issues.apache.org/jira/browse/OAK-5924
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: lucene
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Major
> Fix For: 1.40.0
>
>
> Whenever the index gets updated {{IndexTracker}} detects the changes and open 
> new {{IndexNode}} and closes old index nodes. This flow would block untill 
> all old IndexNode are closed.
> IndexNode close itself relies on a writer lock. It can happen that a long 
> running query i.e. a query which is about to read a page of large is 
> currently executing on the old IndexNode instance. This query is trying load 
> 100k  docs and is very slow (due to loading of excerpt) then such a query 
> would prevent the IndexNode from getting closed. This in turn would prevent 
> the index from seeing latest data and become stale.
> To make query and indexing more resilient we should look if current IndexNode 
> being used for query is closing or not. If closing then query should open a 
> fresh searcher



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OAK-5121) review CommitInfo==null in BackgroundObserver with isExternal change

[Andrei Dulceanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-5121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-5121:
-
Fix Version/s: (was: 1.38.0)
   1.40.0

> review CommitInfo==null in BackgroundObserver with isExternal change
> 
>
> Key: OAK-5121
> URL: https://issues.apache.org/jira/browse/OAK-5121
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: core
>Affects Versions: 1.5.13
>Reporter: Stefan Egli
>Assignee: Chetan Mehrotra
>Priority: Major
> Fix For: 1.40.0
>
> Attachments: OAK-5121.patch
>
>
> OAK-4898 changes CommitInfo to be never null. This is the case outside of the 
> BackgroundObserver - but in the BackgroundObserver itself it is explicitly 
> set to null when compacting. 
> Once OAK-4898 is committed this task is about reviewing the implications in 
> BackgroundObserver wrt compaction and CommitInfo==null



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OAK-5367) Strange path parsing

[Andrei Dulceanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-5367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-5367:
-
Fix Version/s: (was: 1.38.0)
   1.40.0

> Strange path parsing
> 
>
> Key: OAK-5367
> URL: https://issues.apache.org/jira/browse/OAK-5367
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: core
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Major
> Fix For: 1.40.0
>
> Attachments: JcrPathParserTest.java
>
>
> Incorrect handling of path with "\{" was fixed in OAK-5260, but the behavior 
> of the JcrPathParser is still strange. For example:
> * the root node, "/", is mapped to "/", and the current node, "." is mapped 
> to "". But "/." is mapped to the current node (should be root node).
> * "/parent/./childA2" is mapped to "/parent/childA2" (which is fine), but 
> "/parent/.}/childA2" is also mapped to "/parent/childA2".
> * "\}\{" and "}\[" and "}}[" are mapped to the current node. So are ".[" and 
> "/[" and ".}". And "}\{test" is mapped to "}\{test", which is 
> inconsistent-weird.
> * "x\[1\]}" is mapped to "x".
> All that weirdness should be resolved. Some seem to be just weird, but some 
> look like they could become a problem at some point ("}\{").



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OAK-4177) Tests on Mongo should fail if mongo is not available

[Andrei Dulceanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-4177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-4177:
-
Fix Version/s: (was: 1.38.0)
   1.40.0

> Tests on Mongo should fail if mongo is not available
> 
>
> Key: OAK-4177
> URL: https://issues.apache.org/jira/browse/OAK-4177
> Project: Jackrabbit Oak
>  Issue Type: Test
>Reporter: Davide Giannella
>Assignee: Davide Giannella
>Priority: Major
> Fix For: 1.40.0
>
>
> Most if not all of the IT/UT that run against mongodb have an
> assumption at class level that if mongodb is not available the tests
> are skipped.
> The tests should fail instead if mongodb is not available and we
> explicitly said that, via the {{nsfixtures}} flags, we want to run the
> tests against mongodb.
> We currently have 4 fixtures/flags: DOCUMENT_NS, SEGMENT_MK,
> DOCUMENT_RDB, MEMORY_NS.
> https://github.com/apache/jackrabbit-oak/blob/f957b6787eb7a70eba454ceb1cae90bd4d47f15c/oak-commons/src/test/java/org/apache/jackrabbit/oak/commons/FixturesHelper.java#L46
> We may have the need to introduce a new Fixture/Flag that indicate
> that we want to run the tests against Document using the in-memory
> implementation. For example: DOCUMENT_NS_IM.
> This will be useful on the Apache Jenkins as we don't have mongo there
> but we still want to run all the possible Document NS tests against
> the in-memory implementation when this is possible.
> /cc [~mreutegg]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OAK-6759) Convert oak-blob-cloud-azure to OSGi R6 annotations

[Andrei Dulceanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-6759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-6759:
-
Fix Version/s: (was: 1.38.0)
   1.40.0

> Convert oak-blob-cloud-azure to OSGi R6 annotations
> ---
>
> Key: OAK-6759
> URL: https://issues.apache.org/jira/browse/OAK-6759
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: blob-cloud
>Reporter: Robert Munteanu
>Priority: Major
> Fix For: 1.40.0
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OAK-6836) OnRC report

[Andrei Dulceanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-6836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-6836:
-
Fix Version/s: (was: 1.38.0)
   1.40.0

> OnRC report
> ---
>
> Key: OAK-6836
> URL: https://issues.apache.org/jira/browse/OAK-6836
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: segment-tar
>Reporter: Valentin Olteanu
>Priority: Minor
>  Labels: production
> Fix For: 1.40.0
>
> Attachments: gcreport.png
>
>
> Currently, the information regarding an online revision cleanup execution is 
> scattered across multiple log lines and partially available in the attributes 
> of {{SegmentRevisionGarbageCollection}} MBean. 
> While useful for debugging, this is hard to grasp for users that need to 
> understand the full process to be able to read it.
> The idea would be to create a "report" with all the details of an execution 
> and output it at the end - write to log, but also store it in the MBean, from 
> where it can be consumed by monitoring and health checks. 
> In the MBean, this would replace the _Last*_ attributes.
> In the logs, this could replace all the intermediary logs (switch them to 
> DEBUG).



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OAK-6919) SegmentCache might introduce unwanted memory references to SegmentId instances

[Andrei Dulceanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-6919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-6919:
-
Fix Version/s: (was: 1.38.0)
   1.40.0

> SegmentCache might introduce unwanted memory references to SegmentId instances
> --
>
> Key: OAK-6919
> URL: https://issues.apache.org/jira/browse/OAK-6919
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: segment-tar
>Reporter: Francesco Mari
>Priority: Major
> Fix For: 1.40.0
>
>
> {{SegmentCache}} contains, through the underlying Guava cache, hard 
> references to both {{SegmentId}} and {{Segment}} instances. Thus, 
> {{SegmentCache}} contributes to the computation of in-memory references that, 
> in turn, constitute the root references of the garbage collection algorithm.
> Further investigations are needed to assess this statement but, if 
> {{SegmentCache}} is proved to be problematic, there are some possible 
> solutions.
> For example, {{SegmentCache}} might be reworked to store references to 
> MSB/LSB pairs as keys, instead of to {{SegmentId}} instances. Moreover, 
> instead of referencing {{Segment}} instances as values, {{SegmentCache}} 
> might hold references to their underlying {{ByteBuffer}}. With these changes 
> in place, {{SegmentCache}} would not interfere with {{SegmentTracker}} and 
> the garbage collection algorithm.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OAK-8717) Remove deprecated Guava-based APIs

[Andrei Dulceanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-8717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-8717:
-
Fix Version/s: (was: 1.38.0)
   1.40.0

> Remove deprecated Guava-based APIs
> --
>
> Key: OAK-8717
> URL: https://issues.apache.org/jira/browse/OAK-8717
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>Reporter: Julian Reschke
>Priority: Major
> Fix For: 1.40.0
>
> Attachments: OAK-8717.diff
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OAK-7372) Update FileDataStore recommendation

[Andrei Dulceanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-7372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-7372:
-
Fix Version/s: (was: 1.38.0)
   1.40.0

> Update FileDataStore recommendation
> ---
>
> Key: OAK-7372
> URL: https://issues.apache.org/jira/browse/OAK-7372
> Project: Jackrabbit Oak
>  Issue Type: Documentation
>  Components: doc
>Reporter: Marcel Reutegger
>Priority: Minor
> Fix For: 1.40.0
>
>
> The BlobStore documentation currently mentions use of a FileDataStore only 
> for deployments when the data store is shared between multiple repository 
> instances. The documentation should be updated to also recommend the 
> FileDataStore when a repository has many binaries.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OAK-5463) Implement optimized MultiBinaryPropertyState.size(int)

[Andrei Dulceanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-5463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-5463:
-
Fix Version/s: (was: 1.38.0)
   1.40.0

> Implement optimized MultiBinaryPropertyState.size(int)
> --
>
> Key: OAK-5463
> URL: https://issues.apache.org/jira/browse/OAK-5463
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: core
>Reporter: Marcel Reutegger
>Priority: Minor
> Fix For: 1.40.0
>
>
> {{MultiBinaryPropertyState}} currently does not have a {{size(int)}} 
> implementation, which means the base class will convert the {{Blob}} into a 
> String to get the size. This is inefficient and should have an optimized 
> implementation in {{MultiBinaryPropertyState}}.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OAK-6947) Add package export versions for oak-store-spi

[Andrei Dulceanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-6947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-6947:
-
Fix Version/s: (was: 1.38.0)
   1.40.0

> Add package export versions for oak-store-spi
> -
>
> Key: OAK-6947
> URL: https://issues.apache.org/jira/browse/OAK-6947
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: store-spi
>Reporter: Angela Schreiber
>Priority: Major
> Fix For: 1.40.0
>
> Attachments: OAK-6947.patch
>
>
> [~mduerig], [~mreutegg], [~frm], [~stillalex], do you have any strong 
> preferences wrt to the packages we placed in the _oak-store-spi_ module?
> Currently we explicitly export all packages and I think it would make sense 
> to enable the baseline plugin for these packages.
> Any objection from your side?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OAK-4643) Support multiple readers in suggester, spellcheck and faceted search

[Andrei Dulceanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-4643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-4643:
-
Fix Version/s: (was: 1.38.0)
   1.40.0

> Support multiple readers in suggester, spellcheck and faceted search
> 
>
> Key: OAK-4643
> URL: https://issues.apache.org/jira/browse/OAK-4643
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: lucene
>Reporter: Chetan Mehrotra
>Priority: Major
> Fix For: 1.40.0
>
>
> As part of OAK-4566 normal search has been modified to support multiple 
> readers. However for suggester, spellcheck and faceted search the logic is 
> still working with the assumption of single reader. 
> Those parts need to be adapted to support multiple readers



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OAK-5553) Index async index in a new lane without blocking the main lane

[Andrei Dulceanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-5553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-5553:
-
Fix Version/s: (was: 1.38.0)
   1.40.0

> Index async index in a new lane without blocking the main lane
> --
>
> Key: OAK-5553
> URL: https://issues.apache.org/jira/browse/OAK-5553
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: indexing
>Reporter: Chetan Mehrotra
>Priority: Major
> Fix For: 1.40.0
>
>
> Currently if an async index has to be reindex for any reason say update of 
> index definition then this process blocks the indexing of other indexes on 
> that lane. 
> For e.g. if on "async" lane we have 2 indexes /oak:index/fooIndex and 
> /oak:index/barIndex and fooIndex needs to be reindexed. In such a case 
> currently AsyncIndexUpdate would work on reindexing and untill that gets 
> complete other index do not receive any update. If the reindexing takes say 1 
> day then other index would start lagging behind by that time. Note that NRT 
> indexing would help somewhat here.
> To improve this we can implement something similar to what was done for 
> property index in OAK-1456 i.e. provide a way where 
> # an admin can trigger reindex of some async indexes
> # those indexes are moved to different lane and then reindexed
> # post reindexing logic should then move them back to there original lane
> Further this task can then be performed on non leader node as the indexes 
> would not be part of any active lane. Also we may implement it as part of 
> oak-run



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OAK-7423) Document the proc tree

[Andrei Dulceanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-7423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-7423:
-
Fix Version/s: (was: 1.38.0)
   1.40.0

> Document the proc tree
> --
>
> Key: OAK-7423
> URL: https://issues.apache.org/jira/browse/OAK-7423
> Project: Jackrabbit Oak
>  Issue Type: Documentation
>  Components: segment-tar
>Reporter: Francesco Mari
>Priority: Major
>  Labels: technical_debt
> Fix For: 1.40.0
>
>
> The proc tree, contributed in OAK-7416, lacks Javadoc and high-level 
> documentation. In particular, the exposed content structure should be 
> described in greater detail.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OAK-5144) use 'allNodeTypes' of ChangeSet for nodeType-aggregate-filter

[Andrei Dulceanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-5144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-5144:
-
Fix Version/s: (was: 1.38.0)
   1.40.0

> use 'allNodeTypes' of ChangeSet for nodeType-aggregate-filter
> -
>
> Key: OAK-5144
> URL: https://issues.apache.org/jira/browse/OAK-5144
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: jcr
>Affects Versions: 1.5.14
>Reporter: Stefan Egli
>Priority: Major
> Fix For: 1.40.0
>
>
> With OAK-4940 the ChangeSet now contains all node types up to root that are 
> related to a change. This fact could be used by the nodeType-aggregate-filter 
> (OAK-5021), which would likely speed up this type of filter.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OAK-8908) RDBBlobStore on SQL Server: bad performance when default collation is of type SQL*

[Andrei Dulceanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-8908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-8908:
-
Fix Version/s: (was: 1.38.0)
   1.40.0

> RDBBlobStore on SQL Server: bad performance when default collation is of type 
> SQL*
> --
>
> Key: OAK-8908
> URL: https://issues.apache.org/jira/browse/OAK-8908
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: rdbmk
>Reporter: Julian Reschke
>Priority: Major
> Fix For: 1.40.0
>
> Attachments: OAK-8908-1.6.diff, OAK-8908.diff
>
>
> RDBBlobStore uses a 64-char primary key (digest in hex).
> Unfortunately, this causes performance issues on MS SQL Server, when the 
> collation for that column is of type "SQL*" (see links). These types of 
> collations are deprecated, but still the default for installations on the 
> "EN_US" locale.
> The performance loss can be observed by changing the collation on an existing 
> install, and then enable performance logging on RDBBlobStore.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OAK-9324) oak-auth-ldap (UseUidForExtIdTest) tests fail (likely specific to Windows)

[Andrei Dulceanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-9324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-9324:
-
Fix Version/s: (was: 1.38.0)
   1.40.0

> oak-auth-ldap (UseUidForExtIdTest) tests fail (likely specific to Windows)
> --
>
> Key: OAK-9324
> URL: https://issues.apache.org/jira/browse/OAK-9324
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: auth-ldap
>Reporter: Julian Reschke
>Priority: Major
> Fix For: 1.40.0
>
>
> {noformat}
> [INFO] Running 
> org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest
> [ERROR] Tests run: 18, Failures: 0, Errors: 18, Skipped: 0, Time elapsed: 
> 0.184 s <<< FAILURE! - in org.apache.jackrabbit.oak.security.auth
> entication.ldap.impl.UseUidForExtIdTest
> [ERROR] 
> testAuthenticate(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.029 s  <<< ERROR!
> java.lang.reflect.InvocationTargetException
> Caused by: java.io.IOException: Unable to delete file: 
> target\apacheds\cache\c68efd7d-7963-4972-b27c-c2ace6c83b63\ou=system.data
> [ERROR] 
> testAuthenticate(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.029 s  <<< ERROR!
> java.lang.NullPointerException
> [ERROR] 
> testGetGroupByRef(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.021 s  <<< ERROR
> !
> java.lang.reflect.InvocationTargetException
> Caused by: java.io.IOException: Unable to delete file: 
> target\apacheds\cache\c68efd7d-7963-4972-b27c-c2ace6c83b63\ou=system.data
> [ERROR] 
> testGetGroupByRef(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.021 s  <<< ERROR
> !
> java.lang.NullPointerException
> [ERROR] 
> testGetUnknownUserByRef(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.019 s  <<<
>  ERROR!
> java.lang.reflect.InvocationTargetException
> Caused by: java.io.IOException: Unable to delete file: 
> target\apacheds\cache\c68efd7d-7963-4972-b27c-c2ace6c83b63\ou=system.data
> [ERROR] 
> testGetUnknownUserByRef(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.019 s  <<<
>  ERROR!
> java.lang.NullPointerException
> [ERROR] 
> testGetGroups2(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.019 s  <<< ERROR!
> java.lang.reflect.InvocationTargetException
> Caused by: java.io.IOException: Unable to delete file: 
> target\apacheds\cache\c68efd7d-7963-4972-b27c-c2ace6c83b63\ou=system.data
> [ERROR] 
> testGetGroups2(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.019 s  <<< ERROR!
> java.lang.NullPointerException
> [ERROR] 
> testAuthenticateCaseInsensitive(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.02
>  s  <<< ERROR!
> java.lang.reflect.InvocationTargetException
> Caused by: java.io.IOException: Unable to delete file: 
> target\apacheds\cache\c68efd7d-7963-4972-b27c-c2ace6c83b63\ou=system.data
> [ERROR] 
> testAuthenticateCaseInsensitive(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.02
>  s  <<< ERROR!
> java.lang.NullPointerException
> [ERROR] 
> testGetGroups(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.018 s  <<< ERROR!
> java.lang.reflect.InvocationTargetException
> Caused by: java.io.IOException: Unable to delete file: 
> target\apacheds\cache\c68efd7d-7963-4972-b27c-c2ace6c83b63\ou=system.data
> [ERROR] 
> testGetGroups(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.018 s  <<< ERROR!
> java.lang.NullPointerException
> [ERROR] 
> testGetMembers(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.019 s  <<< ERROR!
> java.lang.reflect.InvocationTargetException
> Caused by: java.io.IOException: Unable to delete file: 
> target\apacheds\cache\c68efd7d-7963-4972-b27c-c2ace6c83b63\ou=system.data
> [ERROR] 
> testGetMembers(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.019 s  <<< ERROR!
> java.lang.NullPointerException
> [ERROR] 
> testGetUserByRef(org.apache.jackrabbit.oak.security.authentication.ldap.impl.UseUidForExtIdTest)
>   Time elapsed: 0.019 s  <<< ERROR!
> java.lang.reflect.InvocationTargetException
> Caused by: java.io.IOException: Unable to delete file: 
> target\apacheds\cache\c68efd7d-7963-4972-b27c-c2ace6c83b63\ou=system.data
> [ERROR] 
> 

[jira] [Updated] (OAK-6513) Journal based Async Indexer

[Andrei Dulceanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-6513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-6513:
-
Fix Version/s: (was: 1.38.0)
   1.40.0

> Journal based Async Indexer
> ---
>
> Key: OAK-6513
> URL: https://issues.apache.org/jira/browse/OAK-6513
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: indexing
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Major
> Fix For: 1.40.0
>
>
> Current async indexer design is based on NodeState diff. This has served us 
> fine so far however off late it is not able to perform well if rate of 
> repository writes is high. When changes happen faster than index-update can 
> process them, larger and larger diffs will happen. These make index-updates 
> slower, which again lead to the next diff being ever larger than the one 
> before (assuming a constant ingestion rate). 
> In current diff based flow the indexer performs complete diff for all changes 
> happening between 2 cycle. It may happen that lots of writes happens but not 
> much indexable content is written. So doing diff there is a wasted effort.
> In 1.6 release for NRT Indexing we implemented a journal based indexing for 
> external changes(OAK-4808, OAK-5430). That approach can be generalized and 
> used for async indexing. 
> Before talking about the journal based approach lets see how IndexEditor work 
> currently
> h4. IndexEditor 
> Currently any IndexEditor performs 2 tasks
> # Identify which node is to be indexed based on some index definition. The 
> Editor gets invoked as part of content diff where it determines which 
> NodeState is to be indexed
> # Update the index based on node to be indexed
> For e.g. in oak-lucene we have LuceneIndexEditor which identifies the 
> NodeStates to be indexed and LuceneDocumentMaker which constructs the Lucene 
> Document from NodeState to be indexed. For journal based approach we can 
> decouple these 2 parts and thus have 
> * IndexEditor - Identifies which all paths need to be indexed for given index 
> definition
> * IndexUpdater - Updates the index based on given NodeState and its path
> h4. High Level Flow
> # Session Commit Flow
> ## Each index type would provide a IndexEditor which would be invoked as part 
> of commit (like sync indexes). These IndexEditor would just determine which 
> paths needs to be indexed. 
> ## As part of commit the paths to be indexed would be written to journal. 
> # AsyncIndexUpdate flow
> ## AsyncIndexUpdate would query this journal to fetch all such indexed paths 
> between the 2 checkpoints
> ## Based on the index path data it would invoke the {{IndexUpdater}} to 
> update the index for that path
> ## Merge the index updates
> h4. Benefits
> Such a design would have following impact
> # More work done as part of write
> # Marking of indexable content is distributed hence at indexing time lesser 
> work to be done
> # Indexing can progress in batches 
> # The indexers can be called in parallel
> h4. Journal Implementation
> DocumentNodeStore currently has an in built journal which is being used for 
> NRT Indexing. That feature can be exposed as an api. 
> For scaling index this design is mostly required for cluster case. So we can 
> possibly have both indexing support implemented and use the journal based 
> support for DocumentNodeStore setups. Or we can look into implementing such a 
> journal for SegmentNodeStore setups also
> h4. Open Points
> * Journal support in SegmentNodeStore
> * Handling deletes. 
> Detailed proposal - 
> https://wiki.apache.org/jackrabbit/Journal%20based%20Async%20Indexer



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OAK-6741) Switch to official OSGi component and metatype annotations

[Andrei Dulceanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-6741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-6741:
-
Fix Version/s: (was: 1.38.0)
   1.40.0

> Switch to official OSGi component and metatype annotations
> --
>
> Key: OAK-6741
> URL: https://issues.apache.org/jira/browse/OAK-6741
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>Reporter: Robert Munteanu
>Priority: Major
> Fix For: 1.40.0
>
> Attachments: OAK-6741-proposed-changes-chetans-feedback.patch, 
> osgi-metadata-1.7.8.json, osgi-metadata-trunk.json
>
>
> We should remove the 'old' Felix SCR annotations and move to the 'new' OSGi 
> R6 annotations.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OAK-3767) Provide a way to extend shipped index definitions

[Andrei Dulceanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-3767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-3767:
-
Fix Version/s: (was: 1.38.0)
   1.40.0

> Provide a way to extend shipped index definitions
> -
>
> Key: OAK-3767
> URL: https://issues.apache.org/jira/browse/OAK-3767
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: indexing, query
>Reporter: Davide Giannella
>Priority: Major
> Fix For: 1.40.0
>
>
> We need to provide an explicit support for extending out of the box shipped 
> index definition by an application built on top of Oak. Consider a Sling 
> based app which ships with an index on assets like /oak:index/assetIndex. 
> This application is now used in a project where some project specific 
> extensions are to be done i.e. some new custom asset properties are to be 
> indexed. Currently there are two options
> # Create new duplicate index - For project usage we can create a separate 
> index which includes the project specific properties. This has following 
> downsides
> ## Increases index memory consumption - As both /oak:index/assetIndex and 
> /oak:index/myAssetIndex would index same asset nodes they would be storing 
> the same asset path twice and hence cause an increase in memory consumption 
> by the index
> # Increase in indexing time - With increase in number of indexes at same 
> level the indexing time would increase
> # Ambiguity in index selection - As both indexes index same type of nodes 
> they would compete in answering queries related to assets leading to 
> ambiguity in index selection by query engine. 
> Given above it would be better to avoid such cases and provide an explicit 
> support for extending the index definitions. This can be done by enabling 
> support for adding index definition extensions under a sub directory in a sub 
> directory under /oak:index
> {noformat}
> /oak:index
>   + assetIndex
>   + apps
>  + assetIndex
> {noformat}
> The indexing logic should then use the effective index definition for 
> indexing and querying. 
> *question*. Shall we allow this only under root or under any arbitrary path 
> as well? For example /content.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OAK-9036) Oak should compile & test on Java 15

[Andrei Dulceanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-9036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-9036:
-
Fix Version/s: (was: 1.38.0)
   1.40.0

> Oak should compile & test on Java 15
> 
>
> Key: OAK-9036
> URL: https://issues.apache.org/jira/browse/OAK-9036
> Project: Jackrabbit Oak
>  Issue Type: Epic
>Reporter: Julian Reschke
>Priority: Blocker
> Fix For: 1.40.0
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OAK-6768) Convert oak-remote to OSGi R6 annotations

[Andrei Dulceanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-6768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-6768:
-
Fix Version/s: (was: 1.38.0)
   1.40.0

> Convert oak-remote to OSGi R6 annotations
> -
>
> Key: OAK-6768
> URL: https://issues.apache.org/jira/browse/OAK-6768
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: remoting
>Reporter: Robert Munteanu
>Priority: Major
> Fix For: 1.40.0
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (OAK-5937) Disable query where path restriction is not absolute

[Andrei Dulceanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-5937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu updated OAK-5937:
-
Fix Version/s: (was: 1.38.0)
   1.40.0

> Disable query where path restriction is not absolute
> 
>
> Key: OAK-5937
> URL: https://issues.apache.org/jira/browse/OAK-5937
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: query
>Reporter: Chetan Mehrotra
>Assignee: Thomas Mueller
>Priority: Minor
> Fix For: 1.40.0
>
>
> Query like below cannot be executed in a performant way. We should provide an 
> option to reject such queries
> //content/foo/bar



--
This message was sent by Atlassian Jira
(v8.3.4#803005)