[jira] [Updated] (OAK-8233) new Date.getTime() can be changed to System.currentTimeMillis() to improve performance
[ https://issues.apache.org/jira/browse/OAK-8233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] bd2019us updated OAK-8233: -- Description: Hello, I found that System.currentTimeMillis() can be used here instead of new Date.getTime(). Since new Date() is a thin wrapper of light method System.currentTimeMillis(). The performance will be greatly damaged if it is invoked too much times. According to my local testing at the same environment, System.currentTimeMillis() can achieve a speedup to 5 times (435 ms vs 2073 ms), when these two methods are invoked 5,000,000 times. was: Location: oak-commons/src/main/java/org/apache/jackrabbit/oak/commons/LongUtils.java:52 Hello, I found that System.currentTimeMillis() can be used here instead of new Date.getTime(). Since new Date() is a thin wrapper of light method System.currentTimeMillis(). The performance will be greatly damaged if it is invoked too much times. According to my local testing at the same environment, System.currentTimeMillis() can achieve a speedup to 5 times (435 ms vs 2073 ms), when these two methods are invoked 5,000,000 times. > new Date.getTime() can be changed to System.currentTimeMillis() to improve > performance > -- > > Key: OAK-8233 > URL: https://issues.apache.org/jira/browse/OAK-8233 > Project: Jackrabbit Oak > Issue Type: Bug >Reporter: bd2019us >Priority: Major > Attachments: 1.patch > > > Hello, > I found that System.currentTimeMillis() can be used here instead of new > Date.getTime(). > Since new Date() is a thin wrapper of light method > System.currentTimeMillis(). The performance will be greatly damaged if it is > invoked too much times. > According to my local testing at the same environment, > System.currentTimeMillis() can achieve a speedup to 5 times (435 ms vs 2073 > ms), when these two methods are invoked 5,000,000 times. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-8233) new Date.getTime() can be changed to System.currentTimeMillis() to improve performance
[ https://issues.apache.org/jira/browse/OAK-8233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] bd2019us updated OAK-8233: -- Attachment: 1.patch > new Date.getTime() can be changed to System.currentTimeMillis() to improve > performance > -- > > Key: OAK-8233 > URL: https://issues.apache.org/jira/browse/OAK-8233 > Project: Jackrabbit Oak > Issue Type: Bug >Reporter: bd2019us >Priority: Major > Attachments: 1.patch > > > Location: > oak-commons/src/main/java/org/apache/jackrabbit/oak/commons/LongUtils.java:52 > Hello, > I found that System.currentTimeMillis() can be used here instead of new > Date.getTime(). > Since new Date() is a thin wrapper of light method > System.currentTimeMillis(). The performance will be greatly damaged if it is > invoked too much times. > According to my local testing at the same environment, > System.currentTimeMillis() can achieve a speedup to 5 times (435 ms vs 2073 > ms), when these two methods are invoked 5,000,000 times. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (OAK-8232) Node#setPrimaryType(String) does not create child nodes defined as autoCreated
[ https://issues.apache.org/jira/browse/OAK-8232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16816489#comment-16816489 ] Manfred Baedke edited comment on OAK-8232 at 4/12/19 5:14 PM: -- Attached patch proposal. It's working, but I'm unsure if the code should be moved elsewhere. was (Author: baedke): Attached proposed patch. It's working, but I'm unsure if the code should be moved elsewhere. > Node#setPrimaryType(String) does not create child nodes defined as autoCreated > -- > > Key: OAK-8232 > URL: https://issues.apache.org/jira/browse/OAK-8232 > Project: Jackrabbit Oak > Issue Type: Bug > Components: jcr >Affects Versions: 1.12.0 >Reporter: Manfred Baedke >Priority: Minor > Attachments: oak-8232-testcase.patch, oak-8232.patch > > > In contrast to Node#addNode(String, String), Node#setPrimaryType(String) does > not create child nodes that are defined as autoCreated. See attached failing > test case. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-8232) Node#setPrimaryType(String) does not create child nodes defined as autoCreated
[ https://issues.apache.org/jira/browse/OAK-8232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16816489#comment-16816489 ] Manfred Baedke commented on OAK-8232: - Attached proposed patch. It's working, but I'm unsure if the code should be moved elsewhere. > Node#setPrimaryType(String) does not create child nodes defined as autoCreated > -- > > Key: OAK-8232 > URL: https://issues.apache.org/jira/browse/OAK-8232 > Project: Jackrabbit Oak > Issue Type: Bug > Components: jcr >Affects Versions: 1.12.0 >Reporter: Manfred Baedke >Priority: Minor > Attachments: oak-8232-testcase.patch, oak-8232.patch > > > In contrast to Node#addNode(String, String), Node#setPrimaryType(String) does > not create child nodes that are defined as autoCreated. See attached failing > test case. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-8232) Node#setPrimaryType(String) does not create child nodes defined as autoCreated
[ https://issues.apache.org/jira/browse/OAK-8232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated OAK-8232: Attachment: oak-8232.patch > Node#setPrimaryType(String) does not create child nodes defined as autoCreated > -- > > Key: OAK-8232 > URL: https://issues.apache.org/jira/browse/OAK-8232 > Project: Jackrabbit Oak > Issue Type: Bug > Components: jcr >Affects Versions: 1.12.0 >Reporter: Manfred Baedke >Priority: Minor > Attachments: oak-8232-testcase.patch, oak-8232.patch > > > In contrast to Node#addNode(String, String), Node#setPrimaryType(String) does > not create child nodes that are defined as autoCreated. See attached failing > test case. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-8234) Reduce object allocation in PermissionProviderImpl for admin sessions
[
https://issues.apache.org/jira/browse/OAK-8234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16816297#comment-16816297
]
Alex Deparvu commented on OAK-8234:
---
Proposed patch [0].
In order to keep the change footprint to a minimum, I decided to turn the
{{PermissionProviderImpl}} into a wrapper that would delegate calls to the
admin allow-all version, or the existing version (copy of the current code,
renamed as {{CompiledPermissionProviderImpl}}).
As an interesting aside there's a failing test I had to mark ignore, which
deserves some discussion:
{{PermissionProviderImplTest#testIsGrantedNonExistingVersionStoreLocation}}.
Does it really matter for an admin session if that path actually exists or not?
[~anchela] what do you think?
Also, the benchmark numbers are crazy (20x improvement on
ConcurrentHasPermissionTest):
{noformat}
[trunk]
# ConcurrentHasPermissionTes C min 10% 50% 90% max
N
Import deep tree: 7359
All paths: 123545
Oak-Segment-Tar 10 5 10 64 189 742
6992
[patch]
# ConcurrentHasPermissionTes C min 10% 50% 90% max
N
Import deep tree: 6179
All paths: 123545
Oak-Segment-Tar 10 0 7 8 9 56
75327
{noformat}
[0] https://github.com/apache/jackrabbit-oak/compare/trunk...stillalex:OAK-8234
> Reduce object allocation in PermissionProviderImpl for admin sessions
> -
>
> Key: OAK-8234
> URL: https://issues.apache.org/jira/browse/OAK-8234
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, security
>Reporter: Alex Deparvu
>Assignee: Alex Deparvu
>Priority: Major
>
> There was already a lot of work done here to improve efficiency of admin
> sessions, but we can still do better by simply not creating many of the
> objects needed as parameters for the {{CompiledPermissions}} which will be
> ignored anyway in the case of admin sessions.
> Ex: There are a lot of immutable trees (created via
> {{PermissionUtil.getReadOnlyTree(tree, immutableRoot)}}) that are not used
> for the evaluation.
> Thanks to [~mreutegg] for spotting this one!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (OAK-8234) Reduce object allocation in PermissionProviderImpl for admin sessions
Alex Deparvu created OAK-8234:
-
Summary: Reduce object allocation in PermissionProviderImpl for
admin sessions
Key: OAK-8234
URL: https://issues.apache.org/jira/browse/OAK-8234
Project: Jackrabbit Oak
Issue Type: Improvement
Components: core, security
Reporter: Alex Deparvu
Assignee: Alex Deparvu
There was already a lot of work done here to improve efficiency of admin
sessions, but we can still do better by simply not creating many of the objects
needed as parameters for the {{CompiledPermissions}} which will be ignored
anyway in the case of admin sessions.
Ex: There are a lot of immutable trees (created via
{{PermissionUtil.getReadOnlyTree(tree, immutableRoot)}}) that are not used for
the evaluation.
Thanks to [~mreutegg] for spotting this one!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-8231) Unreachable code in LoginModuleImpl.getLoginId
[
https://issues.apache.org/jira/browse/OAK-8231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16816246#comment-16816246
]
Alex Deparvu commented on OAK-8231:
---
agreed, let's remove this.
> Unreachable code in LoginModuleImpl.getLoginId
> --
>
> Key: OAK-8231
> URL: https://issues.apache.org/jira/browse/OAK-8231
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, security
>Reporter: angela
>Priority: Minor
>
> [~stillalex], as discussed today it seems that the following block in
> {{LoginModuleImpl.getLoginId}} can never be reached
> {code}
>[... here if-statements for 3 types of supported credentials...]
>else {
> try {
> NameCallback callback = new NameCallback("User-ID: ");
> callbackHandler.handle(new Callback[] { callback });
> uid = callback.getName();
> } catch (IOException | UnsupportedCallbackException e) {
> onError();
> log.error(e.getMessage(), e);
> }
> }
> {code}
> the reason for this: that block resides inside an if-statement verifying that
> {{credentials}} are not null. if credentials are not null they will be any of
> the supported classes according to the implementation of {{getCredentials}},
> which will return null if none of the credentials extracted from
> subject/callback/sharedstate is supported.
> as discussed the safest way to deal with this is probably to get rid of that
> block altogether. let me know if you have any concern with that approach.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-8233) new Date.getTime() can be changed to System.currentTimeMillis() to improve performance
[ https://issues.apache.org/jira/browse/OAK-8233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] bd2019us updated OAK-8233: -- Description: Location: oak-commons/src/main/java/org/apache/jackrabbit/oak/commons/LongUtils.java:52 Hello, I found that System.currentTimeMillis() can be used here instead of new Date.getTime(). Since new Date() is a thin wrapper of light method System.currentTimeMillis(). The performance will be greatly damaged if it is invoked too much times. According to my local testing at the same environment, System.currentTimeMillis() can achieve a speedup to 5 times (435 ms vs 2073 ms), when these two methods are invoked 5,000,000 times. was: Location: oak-commons/src/main/java/org/apache/jackrabbit/oak/commons/LongUtils.java:52 Hello, I found that System.currentTimeMillis() can be used here instead of new Date.getTime(). Since new Date() is a thin wrapper of light method System.currentTimeMillis(). The performance will be greatly damaged if it is invoked too much times. According to my local testing at the same environment, System.currentTimeMillis() can achieve a speedup to 5 times (435ms vs 2073ms), when these two methods are invoked 5,000,000 times. > new Date.getTime() can be changed to System.currentTimeMillis() to improve > performance > -- > > Key: OAK-8233 > URL: https://issues.apache.org/jira/browse/OAK-8233 > Project: Jackrabbit Oak > Issue Type: Bug >Reporter: bd2019us >Priority: Major > > Location: > oak-commons/src/main/java/org/apache/jackrabbit/oak/commons/LongUtils.java:52 > Hello, > I found that System.currentTimeMillis() can be used here instead of new > Date.getTime(). > Since new Date() is a thin wrapper of light method > System.currentTimeMillis(). The performance will be greatly damaged if it is > invoked too much times. > According to my local testing at the same environment, > System.currentTimeMillis() can achieve a speedup to 5 times (435 ms vs 2073 > ms), when these two methods are invoked 5,000,000 times. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (OAK-8233) new Date.getTime() can be changed to System.currentTimeMillis() to improve performance
bd2019us created OAK-8233: - Summary: new Date.getTime() can be changed to System.currentTimeMillis() to improve performance Key: OAK-8233 URL: https://issues.apache.org/jira/browse/OAK-8233 Project: Jackrabbit Oak Issue Type: Bug Reporter: bd2019us Location: oak-commons/src/main/java/org/apache/jackrabbit/oak/commons/LongUtils.java:52 Hello, I found that System.currentTimeMillis() can be used here instead of new Date.getTime(). Since new Date() is a thin wrapper of light method System.currentTimeMillis(). The performance will be greatly damaged if it is invoked too much times. According to my local testing at the same environment, System.currentTimeMillis() can achieve a speedup to 5 times (435ms vs 2073ms), when these two methods are invoked 5,000,000 times. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (OAK-8106) High memory usage when large branch is reset
[ https://issues.apache.org/jira/browse/OAK-8106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella closed OAK-8106. - bulk close 1.6.17 > High memory usage when large branch is reset > > > Key: OAK-8106 > URL: https://issues.apache.org/jira/browse/OAK-8106 > Project: Jackrabbit Oak > Issue Type: Bug > Components: documentmk >Affects Versions: 1.6.0, 1.8.0, 1.10.0 >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Major > Fix For: 1.12.0, 1.6.17, 1.10.2, 1.8.13 > > > Resetting a branch with many commits results in high memory usage. The node > state comparison performed by the reset uses an incorrect base state, which > leads to more operations recorded in memory than necessary. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (OAK-8133) Word SHA1 no longer allowed
[
https://issues.apache.org/jira/browse/OAK-8133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella closed OAK-8133.
-
bulk close 1.6.17
> Word SHA1 no longer allowed
> ---
>
> Key: OAK-8133
> URL: https://issues.apache.org/jira/browse/OAK-8133
> Project: Jackrabbit Oak
> Issue Type: Bug
>Reporter: Davide Giannella
>Assignee: Davide Giannella
>Priority: Minor
> Fix For: 1.0.43, 1.12.0, 1.4.25, 1.6.17, 1.8.13, 1.2.32, 1.10.3
>
>
> In the release notes we mention the word {{SHA1}} which is no longer allowed
> and will be bounced back by announce@.
> Remove it from RELEASE-NOTES.txt of all active branches.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (OAK-8123) Build failure with Maven 3.6.0
[
https://issues.apache.org/jira/browse/OAK-8123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella closed OAK-8123.
-
bulk close 1.6.17
> Build failure with Maven 3.6.0
> --
>
> Key: OAK-8123
> URL: https://issues.apache.org/jira/browse/OAK-8123
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: parent
>Affects Versions: 1.0.42, 1.2.31, 1.4.24, 1.6.16
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
>Priority: Minor
> Fix For: 1.0.43, 1.4.25, 1.6.17, 1.2.32
>
>
> The build fails with Maven 3.6.0 on the 1.6 and older branches with an error
> in the findbugs-maven-plugin.
> {noformat}
> Unable to parse configuration of mojo
> org.codehaus.mojo:findbugs-maven-plugin:3.0.0:findbugs for parameter
> pluginArtifacts: Cannot assign configuration entry 'pluginArtifacts' with
> value '${plugin.artifacts}' of type
> java.util.Collections.UnmodifiableRandomAccessList to property of type
> java.util.ArrayList -> [Help 1]
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-8221) Failure to do anything，throw CommitFailedException: OakMerge0004
[
https://issues.apache.org/jira/browse/OAK-8221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16816032#comment-16816032
]
zhouxu commented on OAK-8221:
-
we can schedule revision garbage collection every night。
Is there an example of how to configure DocumentNodeStore for production
environments? Is there an open source system using oak? We can refer to it.
> Failure to do anything，throw CommitFailedException: OakMerge0004
>
>
> Key: OAK-8221
> URL: https://issues.apache.org/jira/browse/OAK-8221
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Reporter: zhouxu
>Priority: Major
>
> Hello expert:
> 1. To use Oak in my project simply add a dependency to
> {{org.apache.jackrabbit:oak-jcr:1.10.2}} and to {{javax.jcr:jcr:2.0。}}
> 2. we construct a Repository instance,use mongodb like this:
> MongoClient
> mongoClient=getMongoClient(mongodbIP,mongodbPort,dbName,userName,password);
> DocumentNodeStore documentNodeStore = newMongoDocumentNodeStoreBuilder()
> .setMongoDB(mongoClient, dbName, 0)
> .setBlobStore(new FileBlobStore("D:\\amberdata\\FileStore"))
> .build();
> Repository repository = new Jcr(new
> Oak(documentNodeStore)).createRepository();
> 3.Every developer uses the oak of a local application to connect to the same
> mongodb,
> A few days later，We failed to unregister node type dw_unit_detail which we
> registered,it takes a long time,and throw CommitFailedException:
> OakMerge0004,like this:
> javax.jcr.InvalidItemStateException: Failed to unregister node type
> dw_unit_detail
> at
> org.apache.jackrabbit.oak.api.CommitFailedException.asRepositoryException(CommitFailedException.java:240)
> at
> org.apache.jackrabbit.oak.plugins.nodetype.write.ReadWriteNodeTypeManager.unregisterNodeType(ReadWriteNodeTypeManager.java:186)
> at com.datamber.afc.domain.type.AfType.destroy(AfType.java:397)
> at com.datamber.afc.domain.type.AfTypeTest.destroy(AfTypeTest.java:345)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> Caused by: org.apache.jackrabbit.oak.api.CommitFailedException: OakMerge0004:
> OakMerge0004: Following exceptions occurred during the bulk update
> operations: [org.apache.jackrabbit.oak.plugins.document.ConflictException:
> The node 3:/jcr:system/jcr:nodeTypes/dw_customize_type was changed in revision
> r16a0699ff58-0-3 (not yet visible), which was applied after the base revision
> r16a0b08f9b6-0-1,r16a067a0c76-0-2,r16a0699faf1-0-3,r16a072d9ee8-0-4,r16a069a45a1-0-5,r16a06874e87-0-6,r16a069be50a-0-7,r16a073313ba-0-8,r16a073e63ae-0-9,r16a0769307d-0-a,r16a0ae97b21-0-b,r16a0a0b1912-0-c,r16a0a0fa4e7-0-d,r16a0a4bbc67-0-e,r16a0a4438fc-0-f,r16a0ae19945-0-10,
> before
> r16a0b099334-0-1] (retries 5, 303136 ms)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch.merge0(DocumentNodeStoreBranch.java:218)
> at
> org.ap
