[jira] [Created] (SLING-2918) I18NFilter ignores RequestLocaleResolver with higher ranking
Joel Richard created SLING-2918: --- Summary: I18NFilter ignores RequestLocaleResolver with higher ranking Key: SLING-2918 URL: https://issues.apache.org/jira/browse/SLING-2918 Project: Sling Issue Type: Improvement Affects Versions: i18n 2.2.4 Environment: Granite Reporter: Joel Richard In the Granite environment a RequestLocaleResolver exists by default. If you install a bundle with another RequestLocaleResolver, it will be ignored - even if it has a higher ranking - because the dependency has already been resolved. This could be fixed easily with adding policyOption=ReferencePolicyOption.GREEDY to the reference. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SLING-3943) Sling persistence API ignores jcr:createdBy property when creating JCR node
[
https://issues.apache.org/jira/browse/SLING-3943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joel Richard updated SLING-3943:
Affects Version/s: (was: Resource Merger 1.1.0)
Resource Resolver 1.1.0
Sling persistence API ignores jcr:createdBy property when creating JCR node
---
Key: SLING-3943
URL: https://issues.apache.org/jira/browse/SLING-3943
Project: Sling
Issue Type: Bug
Components: ResourceResolver
Affects Versions: Resource Resolver 1.1.0
Reporter: Joel Richard
I have the following code:
{code}
Resource channelFolder =
ResourceUtil.getOrCreateResource(resolver, socket.getNamespace().getName(),
sling:OrderedFolder, sling:Folder, false);
MapString, Object props = new HashMapString,
Object();
props.put(jcr:primaryType, nt:unstructured);
props.put(jcr:description, msg);
props.put(jcr:createdBy, user);
resolver.create(channelFolder,
System.currentTimeMillis() + - + user, props);
resolver.commit();
{code}
For whatever reason, the jcr:createdBy property isn't persisted. If I use the
JCR API instead, the jcr:createdBy property is saved.
We use the sling resource resolver in version 1.1.1-R1618115.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (SLING-3943) Sling persistence API ignores jcr:createdBy property when creating JCR node
Joel Richard created SLING-3943:
---
Summary: Sling persistence API ignores jcr:createdBy property when
creating JCR node
Key: SLING-3943
URL: https://issues.apache.org/jira/browse/SLING-3943
Project: Sling
Issue Type: Bug
Components: ResourceResolver
Affects Versions: Resource Merger 1.1.0
Reporter: Joel Richard
I have the following code:
{code}
Resource channelFolder =
ResourceUtil.getOrCreateResource(resolver, socket.getNamespace().getName(),
sling:OrderedFolder, sling:Folder, false);
MapString, Object props = new HashMapString,
Object();
props.put(jcr:primaryType, nt:unstructured);
props.put(jcr:description, msg);
props.put(jcr:createdBy, user);
resolver.create(channelFolder,
System.currentTimeMillis() + - + user, props);
resolver.commit();
{code}
For whatever reason, the jcr:createdBy property isn't persisted. If I use the
JCR API instead, the jcr:createdBy property is saved.
We use the sling resource resolver in version 1.1.1-R1618115.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-3943) Sling persistence API ignores jcr:createdBy property when creating JCR node
[
https://issues.apache.org/jira/browse/SLING-3943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14360121#comment-14360121
]
Joel Richard commented on SLING-3943:
-
[~cziegeler], it might have been org.apache.sling.jcr.resource 2.3.12.
Sling persistence API ignores jcr:createdBy property when creating JCR node
---
Key: SLING-3943
URL: https://issues.apache.org/jira/browse/SLING-3943
Project: Sling
Issue Type: Bug
Components: JCR
Reporter: Joel Richard
I have the following code:
{code}
Resource channelFolder =
ResourceUtil.getOrCreateResource(resolver, socket.getNamespace().getName(),
sling:OrderedFolder, sling:Folder, false);
MapString, Object props = new HashMapString,
Object();
props.put(jcr:primaryType, nt:unstructured);
props.put(jcr:description, msg);
props.put(jcr:createdBy, user);
resolver.create(channelFolder,
System.currentTimeMillis() + - + user, props);
resolver.commit();
{code}
For whatever reason, the jcr:createdBy property isn't persisted. If I use the
JCR API instead, the jcr:createdBy property is saved.
We use the sling resource resolver in version 1.1.1-R1618115.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-3943) Sling persistence API ignores jcr:createdBy property when creating JCR node
[
https://issues.apache.org/jira/browse/SLING-3943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14360118#comment-14360118
]
Joel Richard commented on SLING-3943:
-
[~cziegeler], unfortunately, I don't have a way to figure out the version of
the org.apache.sling.jcr.resource bundle anymore because it isn't a direct
dependency and I have deleted the instance. However, I think it was a pretty
new version when I run into this problem.
Sling persistence API ignores jcr:createdBy property when creating JCR node
---
Key: SLING-3943
URL: https://issues.apache.org/jira/browse/SLING-3943
Project: Sling
Issue Type: Bug
Components: JCR
Reporter: Joel Richard
I have the following code:
{code}
Resource channelFolder =
ResourceUtil.getOrCreateResource(resolver, socket.getNamespace().getName(),
sling:OrderedFolder, sling:Folder, false);
MapString, Object props = new HashMapString,
Object();
props.put(jcr:primaryType, nt:unstructured);
props.put(jcr:description, msg);
props.put(jcr:createdBy, user);
resolver.create(channelFolder,
System.currentTimeMillis() + - + user, props);
resolver.commit();
{code}
For whatever reason, the jcr:createdBy property isn't persisted. If I use the
JCR API instead, the jcr:createdBy property is saved.
We use the sling resource resolver in version 1.1.1-R1618115.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-4544) Performance: MessageFormat shouldn't be used for logging in SlingRequestProgressTracker
[
https://issues.apache.org/jira/browse/SLING-4544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joel Richard updated SLING-4544:
Attachment: Screen Shot 2015-03-25 at 10.42.05.png
Performance: MessageFormat shouldn't be used for logging in
SlingRequestProgressTracker
---
Key: SLING-4544
URL: https://issues.apache.org/jira/browse/SLING-4544
Project: Sling
Issue Type: Improvement
Components: Engine
Affects Versions: Engine 2.4.0
Reporter: Joel Richard
Labels: performance
Attachments: Screen Shot 2015-03-25 at 10.42.05.png
I am profiling an application where up to 5% of the rendering time is spent
in MessageFormat.format for SlingRequestProgressTracker.log (see attached
screenshot). Since the advanced capabilities of MessageFormat are not
required here, it should be rather easy to implement a utility which supports
\{x} as well but is much faster.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (SLING-4544) Performance: MessageFormat shouldn't be used for logging in SlingRequestProgressTracker
Joel Richard created SLING-4544:
---
Summary: Performance: MessageFormat shouldn't be used for logging
in SlingRequestProgressTracker
Key: SLING-4544
URL: https://issues.apache.org/jira/browse/SLING-4544
Project: Sling
Issue Type: Improvement
Components: Engine
Affects Versions: Engine 2.4.0
Reporter: Joel Richard
I am profiling an application where up to 5% of the rendering time is spent in
MessageFormat.format for SlingRequestProgressTracker.log (see attached
screenshot). Since the advanced capabilities of MessageFormat are not required
here, it should be rather easy to implement a utility which supports {x} as
well but is much faster.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-4544) Performance: MessageFormat shouldn't be used for logging in SlingRequestProgressTracker
[
https://issues.apache.org/jira/browse/SLING-4544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joel Richard updated SLING-4544:
Description: I am profiling an application where up to 5% of the rendering
time is spent in MessageFormat.format for SlingRequestProgressTracker.log (see
attached screenshot). Since the advanced capabilities of MessageFormat are not
required here, it should be rather easy to implement a utility which supports
\{x} as well but is much faster. (was: I am profiling an application where up
to 5% of the rendering time is spent in MessageFormat.format for
SlingRequestProgressTracker.log (see attached screenshot). Since the advanced
capabilities of MessageFormat are not required here, it should be rather easy
to implement a utility which supports {x} as well but is much faster.)
Performance: MessageFormat shouldn't be used for logging in
SlingRequestProgressTracker
---
Key: SLING-4544
URL: https://issues.apache.org/jira/browse/SLING-4544
Project: Sling
Issue Type: Improvement
Components: Engine
Affects Versions: Engine 2.4.0
Reporter: Joel Richard
Labels: performance
I am profiling an application where up to 5% of the rendering time is spent
in MessageFormat.format for SlingRequestProgressTracker.log (see attached
screenshot). Since the advanced capabilities of MessageFormat are not
required here, it should be rather easy to implement a utility which supports
\{x} as well but is much faster.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (SLING-4551) Performance: Use static logger in ResourceIterator
Joel Richard created SLING-4551: --- Summary: Performance: Use static logger in ResourceIterator Key: SLING-4551 URL: https://issues.apache.org/jira/browse/SLING-4551 Project: Sling Issue Type: Improvement Components: ResourceResolver Affects Versions: Resource Resolver 1.2.4 Reporter: Joel Richard Priority: Minor The logger lookup in org.apache.sling.resourceresolver.impl.helper.ResourceIterator adds 1% rendering overhead because the logger variable is an instance variable and the class is used very often. This can be avoided simply by using a static logger. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4551) Performance: Use static logger in ResourceIterator
[ https://issues.apache.org/jira/browse/SLING-4551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14386340#comment-14386340 ] Joel Richard commented on SLING-4551: - [~cziegeler], I have reported this one because I know that it's very easy to fix. If we find just ten other little mistakes like this, then we gain already quite a bit. Performance: Use static logger in ResourceIterator -- Key: SLING-4551 URL: https://issues.apache.org/jira/browse/SLING-4551 Project: Sling Issue Type: Improvement Components: ResourceResolver Affects Versions: Resource Resolver 1.2.4 Reporter: Joel Richard Priority: Minor Labels: performance Fix For: Resource Resolver 1.2.6 The logger lookup in org.apache.sling.resourceresolver.impl.helper.ResourceIterator adds 1% rendering overhead because the logger variable is an instance variable and the class is used very often. This can be avoided simply by using a static logger. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (SLING-4532) Performance: DefaultSlingScript has too much overhead
[ https://issues.apache.org/jira/browse/SLING-4532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Richard resolved SLING-4532. - Resolution: Invalid Closing because the overhead is added in a BindingsValuesProvider which is called in DefaultSlingScript.verifySlingBindings and not in DefaultSlingScript itself. Performance: DefaultSlingScript has too much overhead - Key: SLING-4532 URL: https://issues.apache.org/jira/browse/SLING-4532 Project: Sling Issue Type: Improvement Components: Scripting Affects Versions: Scripting Core 2.0.28 Reporter: Joel Richard Labels: performance Attachments: measure.patch While I was profiling a slow page, I saw that a significant amount of time is spent inside DefaultSlingScript. Since profilers often cannot be trusted, I added some code (see attachment) to measure the time spent without the script execution itself (JSP in my case) and came to 8% of the whole page rendering time. Since the JSP itself has been compiled before the measurements, I would have expected the overhead clearly below 1%. The page which I profiled has about 100 sling includes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4544) Performance: MessageFormat shouldn't be used for logging in SlingRequestProgressTracker
[
https://issues.apache.org/jira/browse/SLING-4544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14383784#comment-14383784
]
Joel Richard commented on SLING-4544:
-
[~rombert], although the log-API mentions MessageFormat, I didn't find an
invocation which uses any of the more advanced functionalities. Don't you think
it would be acceptable to write a very limited MessageFormat implementation
which is used here instead of java.text.MessageFormat (and does guarantee to
not throw an exception and would just ignore the advanced formatting
capabilities).
Performance: MessageFormat shouldn't be used for logging in
SlingRequestProgressTracker
---
Key: SLING-4544
URL: https://issues.apache.org/jira/browse/SLING-4544
Project: Sling
Issue Type: Improvement
Components: Engine
Affects Versions: Engine 2.4.0
Reporter: Joel Richard
Labels: performance
Attachments: Screen Shot 2015-03-25 at 10.42.05.png
I am profiling an application where up to 5% of the rendering time is spent
in MessageFormat.format for SlingRequestProgressTracker.log (see attached
screenshot). Since the advanced capabilities of MessageFormat are not
required here, it should be rather easy to implement a utility which supports
\{x} as well but is much faster.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-4532) Performance: DefaultSlingScript has too much overhead
[ https://issues.apache.org/jira/browse/SLING-4532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Richard updated SLING-4532: Labels: performance (was: ) Performance: DefaultSlingScript has too much overhead - Key: SLING-4532 URL: https://issues.apache.org/jira/browse/SLING-4532 Project: Sling Issue Type: Improvement Components: Scripting Affects Versions: Scripting Core 2.0.28 Reporter: Joel Richard Labels: performance Attachments: measure.patch While I was profiling a slow page, I saw that a significant amount of time is spent inside DefaultSlingScript. Since profilers often cannot be trusted, I added some code (see attachment) to measure the time spent without the script execution itself (JSP in my case) and came to 8% of the whole page rendering time. Since the JSP itself has been compiled before the measurements, I would have expected the overhead clearly below 1%. The page which I profiled has about 100 sling includes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4532) Performance: DefaultSlingScript has too much overhead
[ https://issues.apache.org/jira/browse/SLING-4532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Richard updated SLING-4532: Attachment: measure.patch Performance: DefaultSlingScript has too much overhead - Key: SLING-4532 URL: https://issues.apache.org/jira/browse/SLING-4532 Project: Sling Issue Type: Improvement Components: Scripting Affects Versions: Scripting Core 2.0.28 Reporter: Joel Richard Attachments: measure.patch While I was profiling a slow page, I saw that a significant amount of time is spent inside DefaultSlingScript. Since profilers often cannot be trusted, I added some code (see attachment) to measure the time spent without the script execution itself (JSP in my case) and came to 8% of the whole page rendering time. Since the JSP itself has been compiled before the measurements, I would have expected the overhead clearly below 1%. The page which I profiled has about 100 sling includes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-4532) Performance: DefaultSlingScript has too much overhead
Joel Richard created SLING-4532: --- Summary: Performance: DefaultSlingScript has too much overhead Key: SLING-4532 URL: https://issues.apache.org/jira/browse/SLING-4532 Project: Sling Issue Type: Improvement Components: Scripting Affects Versions: Scripting Core 2.0.28 Reporter: Joel Richard Attachments: measure.patch While I was profiling a slow page, I saw that a significant amount of time is spent inside DefaultSlingScript. Since profilers often cannot be trusted, I added some code (see attachment) to measure the time spent without the script execution itself (JSP in my case) and came to 8% of the whole page rendering time. Since the JSP itself has been compiled before the measurements, I would have expected the overhead clearly below 1%. The page which I profiled has about 100 sling includes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-4653) Resource merging properties are ignored if the direct parent of the read resource does not exist
Joel Richard created SLING-4653: --- Summary: Resource merging properties are ignored if the direct parent of the read resource does not exist Key: SLING-4653 URL: https://issues.apache.org/jira/browse/SLING-4653 Project: Sling Issue Type: Bug Components: ResourceResolver Affects Versions: Resource Merger 1.2.8 Reporter: Joel Richard Priority: Critical If the parent of one of the merged resources does not exist, but another resource between the merged resource of the same search path and root has some resource merging properties attached, these properties are ignored in MergingResourceProvider because resource.getParent returns null and then it does not try to traverse to root anymore and therefore does not find these properties. Example: /apps/a with sling:hideChildren=* /libs/a/b/c If you try to read /mnt/overlay/a/b, it will return null. On the other hand, /mnt/overlay/a/b/c will return an unmodified merged resource. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4653) Resource merging properties are ignored if the direct parent of the read resource does not exist
[ https://issues.apache.org/jira/browse/SLING-4653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Richard updated SLING-4653: Description: If the parent of one of the merged resources does not exist, but another resource between the merged resource of the same search path and root has some resource merging properties attached, these properties are ignored in MergingResourceProvider because resource.getParent returns null and then it does not try to traverse to root anymore and therefore does not find these properties. Example: /apps/a with sling:hideChildren=* /libs/a/b/c If you try to read /mnt/overlay/a/b, it will return null. On the other hand, /mnt/overlay/a/b/c will return an unmodified merged resource. *Important:* Consider the performance impact when fixing this issue. See referenced issue for more information. was: If the parent of one of the merged resources does not exist, but another resource between the merged resource of the same search path and root has some resource merging properties attached, these properties are ignored in MergingResourceProvider because resource.getParent returns null and then it does not try to traverse to root anymore and therefore does not find these properties. Example: /apps/a with sling:hideChildren=* /libs/a/b/c If you try to read /mnt/overlay/a/b, it will return null. On the other hand, /mnt/overlay/a/b/c will return an unmodified merged resource. Resource merging properties are ignored if the direct parent of the read resource does not exist Key: SLING-4653 URL: https://issues.apache.org/jira/browse/SLING-4653 Project: Sling Issue Type: Bug Components: ResourceResolver Affects Versions: Resource Merger 1.2.8 Reporter: Joel Richard Priority: Critical If the parent of one of the merged resources does not exist, but another resource between the merged resource of the same search path and root has some resource merging properties attached, these properties are ignored in MergingResourceProvider because resource.getParent returns null and then it does not try to traverse to root anymore and therefore does not find these properties. Example: /apps/a with sling:hideChildren=* /libs/a/b/c If you try to read /mnt/overlay/a/b, it will return null. On the other hand, /mnt/overlay/a/b/c will return an unmodified merged resource. *Important:* Consider the performance impact when fixing this issue. See referenced issue for more information. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4568) Performance: MergingResourceProvider.ParentHidingHandler adds about 30pp rendering overhead
[
https://issues.apache.org/jira/browse/SLING-4568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joel Richard updated SLING-4568:
Attachment: SLING-4568_skip-underlying.patch
[~cziegeler], I have created a new patch (SLING-4568_skip-underlying.patch)
which does not contain the exclude search path configuration and does skip the
ParentHidingHandler also for listChildren and CRUDMergingResourceProvider.
Sorry for the detour, I should have seen before that there are other
ParentHidingHandler usages which should be adjusted as well.
I had to adjust the code in CRUDMergingResourceProvider#getAllResources a
little bit further to prevent that the parent is not read unnecessarily. I even
wanted to create a comment addResourceToHolder method, but this isn't possible
right now because they use different unrelated resource holder classes.
Performance: MergingResourceProvider.ParentHidingHandler adds about 30pp
rendering overhead
---
Key: SLING-4568
URL: https://issues.apache.org/jira/browse/SLING-4568
Project: Sling
Issue Type: Bug
Components: ResourceResolver
Affects Versions: Resource Merger 1.2.8
Reporter: Joel Richard
Assignee: Carsten Ziegeler
Labels: performance
Fix For: Resource Merger 1.2.10
Attachments: SLING-4568_exclude_search_paths.patch,
SLING-4568_experimental_cache.patch, SLING-4568_skip-underlying.patch
When I was analysing all read properties, I noticed a recurring pattern with
sling:hideChildren and jcr:primaryType and that more than 40% of the read
properties are sling:hideChildren. I figured out that sling:hideChildren is
read for all parents in MergingResourceProvider.ParentHidingHandler and that
the requests are processed 30-35pp faster just by commenting out the
constructor code.
Apache Benchmark results with normal ParentHidingHandler:
{quote}
50%272
66%276
75%278
80%281
90%289
95%301
98%493
99%497
{quote}
Results with commented out ParentHidingHandler constructor:
{quote}
50%185
66%188
75%191
80%194
90%202
95%210
98%333
99%338
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-4568) Performance: MergingResourceProvider.ParentHidingHandler adds about 30pp rendering overhead
[
https://issues.apache.org/jira/browse/SLING-4568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joel Richard updated SLING-4568:
Attachment: (was: SLING-4568_skip-underlying.patch)
Performance: MergingResourceProvider.ParentHidingHandler adds about 30pp
rendering overhead
---
Key: SLING-4568
URL: https://issues.apache.org/jira/browse/SLING-4568
Project: Sling
Issue Type: Bug
Components: ResourceResolver
Affects Versions: Resource Merger 1.2.8
Reporter: Joel Richard
Assignee: Carsten Ziegeler
Labels: performance
Fix For: Resource Merger 1.2.10
Attachments: SLING-4568_exclude_search_paths.patch,
SLING-4568_experimental_cache.patch
When I was analysing all read properties, I noticed a recurring pattern with
sling:hideChildren and jcr:primaryType and that more than 40% of the read
properties are sling:hideChildren. I figured out that sling:hideChildren is
read for all parents in MergingResourceProvider.ParentHidingHandler and that
the requests are processed 30-35pp faster just by commenting out the
constructor code.
Apache Benchmark results with normal ParentHidingHandler:
{quote}
50%272
66%276
75%278
80%281
90%289
95%301
98%493
99%497
{quote}
Results with commented out ParentHidingHandler constructor:
{quote}
50%185
66%188
75%191
80%194
90%202
95%210
98%333
99%338
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-4568) Performance: MergingResourceProvider.ParentHidingHandler adds about 30pp rendering overhead
[
https://issues.apache.org/jira/browse/SLING-4568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joel Richard updated SLING-4568:
Attachment: SLING-4568_skip-underlying.patch
[~cziegeler], I have attached the same patch again, but this time created with
git instead of my IDE.
Performance: MergingResourceProvider.ParentHidingHandler adds about 30pp
rendering overhead
---
Key: SLING-4568
URL: https://issues.apache.org/jira/browse/SLING-4568
Project: Sling
Issue Type: Bug
Components: ResourceResolver
Affects Versions: Resource Merger 1.2.8
Reporter: Joel Richard
Assignee: Carsten Ziegeler
Labels: performance
Fix For: Resource Merger 1.2.10
Attachments: SLING-4568_exclude_search_paths.patch,
SLING-4568_experimental_cache.patch, SLING-4568_skip-underlying.patch
When I was analysing all read properties, I noticed a recurring pattern with
sling:hideChildren and jcr:primaryType and that more than 40% of the read
properties are sling:hideChildren. I figured out that sling:hideChildren is
read for all parents in MergingResourceProvider.ParentHidingHandler and that
the requests are processed 30-35pp faster just by commenting out the
constructor code.
Apache Benchmark results with normal ParentHidingHandler:
{quote}
50%272
66%276
75%278
80%281
90%289
95%301
98%493
99%497
{quote}
Results with commented out ParentHidingHandler constructor:
{quote}
50%185
66%188
75%191
80%194
90%202
95%210
98%333
99%338
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Reopened] (SLING-4568) Performance: MergingResourceProvider.ParentHidingHandler adds about 30pp rendering overhead
[
https://issues.apache.org/jira/browse/SLING-4568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joel Richard reopened SLING-4568:
-
Reopening because the applied patch was incomplete.
Performance: MergingResourceProvider.ParentHidingHandler adds about 30pp
rendering overhead
---
Key: SLING-4568
URL: https://issues.apache.org/jira/browse/SLING-4568
Project: Sling
Issue Type: Bug
Components: ResourceResolver
Affects Versions: Resource Merger 1.2.8
Reporter: Joel Richard
Assignee: Carsten Ziegeler
Labels: performance
Fix For: Resource Merger 1.2.10
Attachments: SLING-4568_exclude_search_paths.patch,
SLING-4568_experimental_cache.patch
When I was analysing all read properties, I noticed a recurring pattern with
sling:hideChildren and jcr:primaryType and that more than 40% of the read
properties are sling:hideChildren. I figured out that sling:hideChildren is
read for all parents in MergingResourceProvider.ParentHidingHandler and that
the requests are processed 30-35pp faster just by commenting out the
constructor code.
Apache Benchmark results with normal ParentHidingHandler:
{quote}
50%272
66%276
75%278
80%281
90%289
95%301
98%493
99%497
{quote}
Results with commented out ParentHidingHandler constructor:
{quote}
50%185
66%188
75%191
80%194
90%202
95%210
98%333
99%338
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-4568) Performance: MergingResourceProvider.ParentHidingHandler adds about 30pp rendering overhead
[
https://issues.apache.org/jira/browse/SLING-4568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joel Richard updated SLING-4568:
Attachment: SLING-4568_skip-underlying_3.patch
[~cziegeler], I wasn't aware of your changes, but I have merged them and it
should hopefully work now.
Performance: MergingResourceProvider.ParentHidingHandler adds about 30pp
rendering overhead
---
Key: SLING-4568
URL: https://issues.apache.org/jira/browse/SLING-4568
Project: Sling
Issue Type: Bug
Components: ResourceResolver
Affects Versions: Resource Merger 1.2.8
Reporter: Joel Richard
Assignee: Carsten Ziegeler
Labels: performance
Fix For: Resource Merger 1.2.10
Attachments: SLING-4568_exclude_search_paths.patch,
SLING-4568_experimental_cache.patch, SLING-4568_skip-underlying.patch,
SLING-4568_skip-underlying_3.patch
When I was analysing all read properties, I noticed a recurring pattern with
sling:hideChildren and jcr:primaryType and that more than 40% of the read
properties are sling:hideChildren. I figured out that sling:hideChildren is
read for all parents in MergingResourceProvider.ParentHidingHandler and that
the requests are processed 30-35pp faster just by commenting out the
constructor code.
Apache Benchmark results with normal ParentHidingHandler:
{quote}
50%272
66%276
75%278
80%281
90%289
95%301
98%493
99%497
{quote}
Results with commented out ParentHidingHandler constructor:
{quote}
50%185
66%188
75%191
80%194
90%202
95%210
98%333
99%338
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-4568) Performance: MergingResourceProvider.ParentHidingHandler adds about 30pp rendering overhead
[
https://issues.apache.org/jira/browse/SLING-4568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joel Richard updated SLING-4568:
Attachment: (was: SLING-4568_skip-underlying.patch)
Performance: MergingResourceProvider.ParentHidingHandler adds about 30pp
rendering overhead
---
Key: SLING-4568
URL: https://issues.apache.org/jira/browse/SLING-4568
Project: Sling
Issue Type: Bug
Components: ResourceResolver
Affects Versions: Resource Merger 1.2.8
Reporter: Joel Richard
Assignee: Carsten Ziegeler
Labels: performance
Fix For: Resource Merger 1.2.10
Attachments: SLING-4568_exclude_search_paths.patch,
SLING-4568_experimental_cache.patch, SLING-4568_skip-underlying_3.patch
When I was analysing all read properties, I noticed a recurring pattern with
sling:hideChildren and jcr:primaryType and that more than 40% of the read
properties are sling:hideChildren. I figured out that sling:hideChildren is
read for all parents in MergingResourceProvider.ParentHidingHandler and that
the requests are processed 30-35pp faster just by commenting out the
constructor code.
Apache Benchmark results with normal ParentHidingHandler:
{quote}
50%272
66%276
75%278
80%281
90%289
95%301
98%493
99%497
{quote}
Results with commented out ParentHidingHandler constructor:
{quote}
50%185
66%188
75%191
80%194
90%202
95%210
98%333
99%338
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-3944) org.apache.sling.scripting.java bundle exports javax.inject package in wrong version
[ https://issues.apache.org/jira/browse/SLING-3944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Richard updated SLING-3944: Attachment: Screen Shot 2015-05-06 at 12.36.05.png [~olli], the exported version is now 0, but it seems like the imported version has been set to [0.0, 1) because of this (see attached screenshot). Won't that cause further problems? org.apache.sling.scripting.java bundle exports javax.inject package in wrong version Key: SLING-3944 URL: https://issues.apache.org/jira/browse/SLING-3944 Project: Sling Issue Type: Bug Components: Scripting Affects Versions: Scripting Java 2.0.10 Reporter: Markus Haack Assignee: Oliver Lietz Priority: Critical Fix For: Scripting Java 2.0.12 Attachments: Screen Shot 2015-05-06 at 12.36.05.png The org.apache.sling.scripting.java bundle exports the package javax.inject in the version of the bundle, which is wrong and should be fixed. This can lead to bundle version problems for other bundles which depend on javax.inject in version [1.0,2) - the correct version (like Jersey Web Services libraries). Either export javax.inject with version 0.0.0 or even better with the correct version 1.0.0. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-3944) org.apache.sling.scripting.java bundle exports javax.inject package in wrong version
[ https://issues.apache.org/jira/browse/SLING-3944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14532297#comment-14532297 ] Joel Richard commented on SLING-3944: - @Carsten Ziegler, nothing concrete, I am just wondering whether the import of javax.inject version 0 could cause further problems. Looks weird too me. If that's fine, then you can ignore my comments. org.apache.sling.scripting.java bundle exports javax.inject package in wrong version Key: SLING-3944 URL: https://issues.apache.org/jira/browse/SLING-3944 Project: Sling Issue Type: Bug Components: Scripting Affects Versions: Scripting Java 2.0.10 Reporter: Markus Haack Assignee: Oliver Lietz Priority: Critical Fix For: Scripting Java 2.0.12 Attachments: Screen Shot 2015-05-06 at 12.36.05.png The org.apache.sling.scripting.java bundle exports the package javax.inject in the version of the bundle, which is wrong and should be fixed. This can lead to bundle version problems for other bundles which depend on javax.inject in version [1.0,2) - the correct version (like Jersey Web Services libraries). Either export javax.inject with version 0.0.0 or even better with the correct version 1.0.0. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4626) NullPointerExceptions in MockResourceResolver
[ https://issues.apache.org/jira/browse/SLING-4626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Richard updated SLING-4626: Attachment: SLING-4626.patch NullPointerExceptions in MockResourceResolver - Key: SLING-4626 URL: https://issues.apache.org/jira/browse/SLING-4626 Project: Sling Issue Type: Bug Components: Testing Affects Versions: Testing ResourceResolver Mock 1.1.4 Reporter: Joel Richard Priority: Minor Attachments: SLING-4626.patch The MockResourceResolver throws an exception when trying to access a resource outside of the root. The normal ResourceResolver implementation returns just null instead. Moreover, I get another NullPointerException in MockValueMap#convertForWrite if I try to create a MockResource with null properties (which is for example done in MergedResourceTest). Patch is attached. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-4626) NullPointerExceptions in MockResourceResolver
Joel Richard created SLING-4626: --- Summary: NullPointerExceptions in MockResourceResolver Key: SLING-4626 URL: https://issues.apache.org/jira/browse/SLING-4626 Project: Sling Issue Type: Bug Components: Testing Affects Versions: Testing ResourceResolver Mock 1.1.4 Reporter: Joel Richard Priority: Minor The MockResourceResolver throws an exception when trying to access a resource outside of the root. The normal ResourceResolver implementation returns just null instead. Moreover, I get another NullPointerException in MockValueMap#convertForWrite if I try to create a MockResource with null properties (which is for example done in MergedResourceTest). Patch is attached. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4596) Performance: Consider optimizing JcrItemResource#getParent and getChild
[ https://issues.apache.org/jira/browse/SLING-4596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Richard updated SLING-4596: Attachment: SLING-4596_experimental.patch I have attached an experimental patch which improves the rendering performance for 18%-25% (tested on two different pages). Please notice that I added the OptimizableResourceProvider interface only to a new package for my convenience (otherwise I would have had to update a lot of bundles). Performance: Consider optimizing JcrItemResource#getParent and getChild --- Key: SLING-4596 URL: https://issues.apache.org/jira/browse/SLING-4596 Project: Sling Issue Type: Improvement Components: JCR, ResourceResolver Affects Versions: JCR Resource 2.5.0 Reporter: Joel Richard Priority: Critical Labels: performance Attachments: JcrNodeResource_getParent.patch, SLING-4596_experimental.patch I have noticed that on some resource intensive pages up to 24% of the rendering time is spent in AbstractResource.getParent. One of the main reasons for this is because the ParentHidingHandler traverses for each resource to the root (see SLING-4568). getParent is not just called often, but is also about 10 times slower than jcrNode.getParent() which has the following reasons: - itemExists is called unnecessary because JcrResourceProvider#createResource does not know that the path belongs to a parent of a node which has already been read. See also SLING-4585. - jcrSession.getItem (which is used to read parents in JcrResourceProvider#createResource) is about 3.5 times slower than jcrNode.getParent in Oak. - Some other overhead which cannot be avoided entirely. The situation could be improved with a getParent implementation which is specific to JcrNodeResource and uses getNode().getParent() directly to create a new JcrNodeResource. I have implemented such a method (see attached experimental patch) and it reduces the time for getParent from 24% to 5% on my test page. As discussed on the [mailing list|http://mail-archives.apache.org/mod_mbox/sling-dev/201504.mbox/%3C55266BB2.1050506%40apache.org%3E] this is not a good solution because the parent resource could be backed by another provider. An alternative approach would be to create a new resource provider interface which accepts the base resource (which is passed to resourceResolver.getResource), retrieves the node form it and uses it for a direct getParent/getNode call (see the linked mail for more information). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4611) Performance: Consider optimizing MergedResource#getParent and getChild
[ https://issues.apache.org/jira/browse/SLING-4611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Richard updated SLING-4611: Attachment: SLING-4611_experimental.patch I have attached an experimental patch which improves the rendering performance in combination with the patch from SLING-4596 for 28%-39% (tested on two different pages). This patch depends on the other one and must not be applied alone. In order to make the resourcemerger tests passing again, the patch from SLING-4626 has to be applied as well. Performance: Consider optimizing MergedResource#getParent and getChild -- Key: SLING-4611 URL: https://issues.apache.org/jira/browse/SLING-4611 Project: Sling Issue Type: Improvement Components: ResourceResolver Affects Versions: Resource Merger 1.2.8 Reporter: Joel Richard Priority: Critical Labels: perfomance Attachments: SLING-4611_experimental.patch For some pages up to 29% of the rendering time is spent in AbstractResource.getChild. In my case, 75% of the resources are MergedResources and the rest are JcrNodeResources (for which I have already opened SLING-4596). Therefore, I would suggest implementing the following optimization: The merged resources should be stored in MergedResource and when getChild is called, it would use getChild on them directly and merge the child resources. This would have the advantage that the ParentHidingHandler would not have to be called again for the parent resources and could even make SLING-4568 obsolete. Moreover, it would leverage optimizations of the merged resource implementations (e.g. SLING-4596 for JcrNodeResource#getChild). A problem with this approach is that possible in JCR (and maybe also some other resource providers) to set ACLs which allow to read children but not their parents. Therefore, getChild will in addition have to check for each search path which isn't covered with a merged resource if this path does really not exist. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4584) Performance: XSSAPI.getValidHref should not be based on HTML filtering
[ https://issues.apache.org/jira/browse/SLING-4584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Richard updated SLING-4584: Attachment: SLING-4584.patch I have implemented a patch which uses some AntiSamy internals to implement getValidHref without having to parse a whole html link and is thereof much faster. All tests do still pass. Please review and let me know what you think. Performance: XSSAPI.getValidHref should not be based on HTML filtering -- Key: SLING-4584 URL: https://issues.apache.org/jira/browse/SLING-4584 Project: Sling Issue Type: Improvement Affects Versions: XSS Protection API 1.0.2 Reporter: Joel Richard Labels: perfomance, xss Attachments: SLING-4584.patch Around 3% of the rendering time is spent in getValidHref because it uses AntiSamy (which is a HTML filter) to do the job. This is obviously a hack and adds a lot of unnecessary overhead. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4568) Performance: MergingResourceProvider.ParentHidingHandler adds about 30pp rendering overhead
[
https://issues.apache.org/jira/browse/SLING-4568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joel Richard updated SLING-4568:
Attachment: (was: SLING-4568.patch)
Performance: MergingResourceProvider.ParentHidingHandler adds about 30pp
rendering overhead
---
Key: SLING-4568
URL: https://issues.apache.org/jira/browse/SLING-4568
Project: Sling
Issue Type: Bug
Components: ResourceResolver
Affects Versions: Resource Merger 1.2.8
Reporter: Joel Richard
Priority: Critical
Labels: performance
When I was analysing all read properties, I noticed a recurring pattern with
sling:hideChildren and jcr:primaryType and that more than 40% of the read
properties are sling:hideChildren. I figured out that sling:hideChildren is
read for all parents in MergingResourceProvider.ParentHidingHandler and that
the requests are processed 30-35pp faster just by commenting out the
constructor code.
Apache Benchmark results with normal ParentHidingHandler:
{quote}
50%272
66%276
75%278
80%281
90%289
95%301
98%493
99%497
{quote}
Results with commented out ParentHidingHandler constructor:
{quote}
50%185
66%188
75%191
80%194
90%202
95%210
98%333
99%338
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-4568) Performance: MergingResourceProvider.ParentHidingHandler adds about 30pp rendering overhead
[
https://issues.apache.org/jira/browse/SLING-4568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joel Richard updated SLING-4568:
Attachment: SLING-4568_exclude_search_paths.patch
SLING-4568_experimental_cache.patch
I have renamed to previous patch to SLING-4568_experimental_cache.patch and
attached a new patch which is simpler and even more efficient. It includes two
changes:
* It let's you exclude search paths which should not be merged. In our case, we
have 4 different search paths, but only two are relevant for the merging. By
adding them to the excluded list, a lot of unnecessary getResource calls are
avoided. Moreover, it makes it possible for us to benefit from the more
important second change.
* The ParentHidingHandler is not not executed anymore for the last not excluded
search path and is therefore only executed for the real overlays. This makes
the MergingResourceProvider overhead negligible in most cases and makes the
cache from the first patch irrelevant.
Performance: MergingResourceProvider.ParentHidingHandler adds about 30pp
rendering overhead
---
Key: SLING-4568
URL: https://issues.apache.org/jira/browse/SLING-4568
Project: Sling
Issue Type: Bug
Components: ResourceResolver
Affects Versions: Resource Merger 1.2.8
Reporter: Joel Richard
Priority: Critical
Labels: performance
Attachments: SLING-4568_exclude_search_paths.patch,
SLING-4568_experimental_cache.patch
When I was analysing all read properties, I noticed a recurring pattern with
sling:hideChildren and jcr:primaryType and that more than 40% of the read
properties are sling:hideChildren. I figured out that sling:hideChildren is
read for all parents in MergingResourceProvider.ParentHidingHandler and that
the requests are processed 30-35pp faster just by commenting out the
constructor code.
Apache Benchmark results with normal ParentHidingHandler:
{quote}
50%272
66%276
75%278
80%281
90%289
95%301
98%493
99%497
{quote}
Results with commented out ParentHidingHandler constructor:
{quote}
50%185
66%188
75%191
80%194
90%202
95%210
98%333
99%338
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (SLING-4611) Performance: Consider optimizing MergedResource#getParent and getChild
Joel Richard created SLING-4611: --- Summary: Performance: Consider optimizing MergedResource#getParent and getChild Key: SLING-4611 URL: https://issues.apache.org/jira/browse/SLING-4611 Project: Sling Issue Type: Improvement Components: ResourceResolver Affects Versions: Resource Merger 1.2.8 Reporter: Joel Richard Priority: Critical For some pages up to 29% of the rendering time is spent in AbstractResource.getChild. In my case, 75% of the resources are MergedResources and the rest are JcrNodeResources (for which I have already opened SLING-4596). Therefore, I would suggest implementing the following optimization: The merged resources should be stored in MergedResource and when getChild is called, it would use getChild on them directly and merge the child resources. This would have the advantage that the ParentHidingHandler would not have to be called again for the parent resources and could even make SLING-4568 obsolete. Moreover, it would leverage optimizations of the merged resource implementations (e.g. SLING-4596 for JcrNodeResource#getChild). A problem with this approach is that possible in JCR (and maybe also some other resource providers) to set ACLs which allow to read children but not their parents. Therefore, getChild will in addition have to check for each search path which isn't covered with a merged resource if this path does really not exist. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4611) Performance: Consider optimizing MergedResource#getParent and getChild
[ https://issues.apache.org/jira/browse/SLING-4611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14492383#comment-14492383 ] Joel Richard commented on SLING-4611: - The idea is basically the same as in SLING-4596 just for MergedResource. One way of implementing it which should work in all cases would be the following: # Store the mappedResources which are already passed to the MergedResource constructor in the object. # Introduce the ResourceProvider API which is described in SLING-4596 and accepts the base resource for getResource. # Check in getResource whether the base resource is also MergedResource and if so get all mapped resources. # Call getChild for each mapped resource. If the resource is a JcrNodeResource, it would benefit here from the SLING-4596 optimization. # Next it would have to check which search paths aren't covered with the mapped resources and try to get the resources for theses. In most cases getResource will return null for these (because the parent couldn't be read either). # Combine the resources from both sources and merge them. Performance: Consider optimizing MergedResource#getParent and getChild -- Key: SLING-4611 URL: https://issues.apache.org/jira/browse/SLING-4611 Project: Sling Issue Type: Improvement Components: ResourceResolver Affects Versions: Resource Merger 1.2.8 Reporter: Joel Richard Priority: Critical Labels: perfomance For some pages up to 29% of the rendering time is spent in AbstractResource.getChild. In my case, 75% of the resources are MergedResources and the rest are JcrNodeResources (for which I have already opened SLING-4596). Therefore, I would suggest implementing the following optimization: The merged resources should be stored in MergedResource and when getChild is called, it would use getChild on them directly and merge the child resources. This would have the advantage that the ParentHidingHandler would not have to be called again for the parent resources and could even make SLING-4568 obsolete. Moreover, it would leverage optimizations of the merged resource implementations (e.g. SLING-4596 for JcrNodeResource#getChild). A problem with this approach is that possible in JCR (and maybe also some other resource providers) to set ACLs which allow to read children but not their parents. Therefore, getChild will in addition have to check for each search path which isn't covered with a merged resource if this path does really not exist. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4568) Performance: MergingResourceProvider.ParentHidingHandler adds about 30% rendering overhead
[
https://issues.apache.org/jira/browse/SLING-4568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14482731#comment-14482731
]
Joel Richard commented on SLING-4568:
-
Instead of a simple HashMap we could use a data structure dedicated for caches
(which is limited or where the items expire). It would probably also make sense
to clear the cache in commit(). Another approach would be to enable this cache
only for requests or even only for GET requests.
Performance: MergingResourceProvider.ParentHidingHandler adds about 30%
rendering overhead
--
Key: SLING-4568
URL: https://issues.apache.org/jira/browse/SLING-4568
Project: Sling
Issue Type: Bug
Components: ResourceResolver
Affects Versions: Resource Merger 1.2.8
Reporter: Joel Richard
Priority: Critical
Labels: performance
Attachments: SLING-4568.patch
When I was analysing all read properties, I noticed a recurring pattern with
sling:hideChildren and jcr:primaryType and that more than 40% of the read
properties are sling:hideChildren. I figured out that sling:hideChildren is
read for all parents in MergingResourceProvider.ParentHidingHandler and that
the requests are processed 30-35% faster just by commenting out the
constructor code.
Apache Benchmark results with normal ParentHidingHandler:
{quote}
50%272
66%276
75%278
80%281
90%289
95%301
98%493
99%497
{quote}
Results with commented out ParentHidingHandler constructor:
{quote}
50%185
66%188
75%191
80%194
90%202
95%210
98%333
99%338
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-4568) Performance: MergingResourceProvider.ParentHidingHandler adds about 30% rendering overhead
[
https://issues.apache.org/jira/browse/SLING-4568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14482696#comment-14482696
]
Joel Richard commented on SLING-4568:
-
[~cziegeler], the cache is bound to a resource resolver and will therefore not
last longer than the resource resolver itself.
Performance: MergingResourceProvider.ParentHidingHandler adds about 30%
rendering overhead
--
Key: SLING-4568
URL: https://issues.apache.org/jira/browse/SLING-4568
Project: Sling
Issue Type: Bug
Components: ResourceResolver
Affects Versions: Resource Merger 1.2.8
Reporter: Joel Richard
Priority: Critical
Labels: performance
Attachments: SLING-4568.patch
When I was analysing all read properties, I noticed a recurring pattern with
sling:hideChildren and jcr:primaryType and that more than 40% of the read
properties are sling:hideChildren. I figured out that sling:hideChildren is
read for all parents in MergingResourceProvider.ParentHidingHandler and that
the requests are processed 30-35% faster just by commenting out the
constructor code.
Apache Benchmark results with normal ParentHidingHandler:
{quote}
50%272
66%276
75%278
80%281
90%289
95%301
98%493
99%497
{quote}
Results with commented out ParentHidingHandler constructor:
{quote}
50%185
66%188
75%191
80%194
90%202
95%210
98%333
99%338
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (SLING-4584) Performance: XSSAPI.getValidHref should not be based on HTML filtering
Joel Richard created SLING-4584: --- Summary: Performance: XSSAPI.getValidHref should not be based on HTML filtering Key: SLING-4584 URL: https://issues.apache.org/jira/browse/SLING-4584 Project: Sling Issue Type: Improvement Affects Versions: XSS Protection API 1.0.2 Reporter: Joel Richard Around 3% of the rendering time is spent in getValidHref because it uses AntiSamy (which is a HTML filter) to do the job. This is obviously a hack and adds a lot of unnecessary overhead. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-4585) Performance: Use JackrabbitSession#getItemOrNull to speed up JcrResourceProvider#createResource
Joel Richard created SLING-4585: --- Summary: Performance: Use JackrabbitSession#getItemOrNull to speed up JcrResourceProvider#createResource Key: SLING-4585 URL: https://issues.apache.org/jira/browse/SLING-4585 Project: Sling Issue Type: Improvement Components: JCR, ResourceResolver Affects Versions: JCR Resource 2.5.0 Reporter: Joel Richard Priority: Critical If the current session is a JackrabbitSession, JcrResourceProvider should use getItemOrNull (as soon as exported) to save rendering time. See referenced issue and the following mail thread for more information: http://mail-archives.apache.org/mod_mbox/jackrabbit-oak-dev/201504.mbox/browser -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4585) Performance: Use JackrabbitSession#getItemOrNull to speed up JcrResourceProvider#createResource
[ https://issues.apache.org/jira/browse/SLING-4585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Richard updated SLING-4585: Description: If the current session is a JackrabbitSession, JcrResourceProvider should use getItemOrNull (as soon as exported) to save rendering time. See referenced issue and the following mail thread for more information: http://mail-archives.apache.org/mod_mbox/jackrabbit-oak-dev/201504.mbox/%3CD1495A09.3B670%25anchela%40adobe.com%3E was: If the current session is a JackrabbitSession, JcrResourceProvider should use getItemOrNull (as soon as exported) to save rendering time. See referenced issue and the following mail thread for more information: http://mail-archives.apache.org/mod_mbox/jackrabbit-oak-dev/201504.mbox/browser Performance: Use JackrabbitSession#getItemOrNull to speed up JcrResourceProvider#createResource --- Key: SLING-4585 URL: https://issues.apache.org/jira/browse/SLING-4585 Project: Sling Issue Type: Improvement Components: JCR, ResourceResolver Affects Versions: JCR Resource 2.5.0 Reporter: Joel Richard Priority: Critical Labels: performance If the current session is a JackrabbitSession, JcrResourceProvider should use getItemOrNull (as soon as exported) to save rendering time. See referenced issue and the following mail thread for more information: http://mail-archives.apache.org/mod_mbox/jackrabbit-oak-dev/201504.mbox/%3CD1495A09.3B670%25anchela%40adobe.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (SLING-4585) Performance: Use JackrabbitSession#getItemOrNull to speed up JcrResourceProvider#createResource
[ https://issues.apache.org/jira/browse/SLING-4585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Richard updated SLING-4585: Comment: was deleted (was: Is there a way to achieve this without using a try/catch to detect whether the method is available or using reflection?) Performance: Use JackrabbitSession#getItemOrNull to speed up JcrResourceProvider#createResource --- Key: SLING-4585 URL: https://issues.apache.org/jira/browse/SLING-4585 Project: Sling Issue Type: Improvement Components: JCR, ResourceResolver Affects Versions: JCR Resource 2.5.0 Reporter: Joel Richard Priority: Critical Labels: performance If the current session is a JackrabbitSession, JcrResourceProvider should use getItemOrNull (as soon as exported) to save rendering time. See referenced issue and the following mail thread for more information: http://mail-archives.apache.org/mod_mbox/jackrabbit-oak-dev/201504.mbox/browser -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4585) Performance: Use JackrabbitSession#getItemOrNull to speed up JcrResourceProvider#createResource
[ https://issues.apache.org/jira/browse/SLING-4585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14483150#comment-14483150 ] Joel Richard commented on SLING-4585: - Is there a way to achieve this without using a try/catch to detect whether the method is available or using reflection? Performance: Use JackrabbitSession#getItemOrNull to speed up JcrResourceProvider#createResource --- Key: SLING-4585 URL: https://issues.apache.org/jira/browse/SLING-4585 Project: Sling Issue Type: Improvement Components: JCR, ResourceResolver Affects Versions: JCR Resource 2.5.0 Reporter: Joel Richard Priority: Critical Labels: performance If the current session is a JackrabbitSession, JcrResourceProvider should use getItemOrNull (as soon as exported) to save rendering time. See referenced issue and the following mail thread for more information: http://mail-archives.apache.org/mod_mbox/jackrabbit-oak-dev/201504.mbox/browser -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4585) Performance: Use JackrabbitSession#getItemOrNull to speed up JcrResourceProvider#createResource
[ https://issues.apache.org/jira/browse/SLING-4585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14483151#comment-14483151 ] Joel Richard commented on SLING-4585: - Is there a way to achieve this without using a try/catch to detect whether the method is available or using reflection? Performance: Use JackrabbitSession#getItemOrNull to speed up JcrResourceProvider#createResource --- Key: SLING-4585 URL: https://issues.apache.org/jira/browse/SLING-4585 Project: Sling Issue Type: Improvement Components: JCR, ResourceResolver Affects Versions: JCR Resource 2.5.0 Reporter: Joel Richard Priority: Critical Labels: performance If the current session is a JackrabbitSession, JcrResourceProvider should use getItemOrNull (as soon as exported) to save rendering time. See referenced issue and the following mail thread for more information: http://mail-archives.apache.org/mod_mbox/jackrabbit-oak-dev/201504.mbox/browser -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4568) Performance: MergingResourceProvider.ParentHidingHandler adds about 30pp rendering overhead
[
https://issues.apache.org/jira/browse/SLING-4568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joel Richard updated SLING-4568:
Summary: Performance: MergingResourceProvider.ParentHidingHandler adds
about 30pp rendering overhead (was: Performance:
MergingResourceProvider.ParentHidingHandler adds about 30% rendering overhead)
Performance: MergingResourceProvider.ParentHidingHandler adds about 30pp
rendering overhead
---
Key: SLING-4568
URL: https://issues.apache.org/jira/browse/SLING-4568
Project: Sling
Issue Type: Bug
Components: ResourceResolver
Affects Versions: Resource Merger 1.2.8
Reporter: Joel Richard
Priority: Critical
Labels: performance
Attachments: SLING-4568.patch
When I was analysing all read properties, I noticed a recurring pattern with
sling:hideChildren and jcr:primaryType and that more than 40% of the read
properties are sling:hideChildren. I figured out that sling:hideChildren is
read for all parents in MergingResourceProvider.ParentHidingHandler and that
the requests are processed 30-35% faster just by commenting out the
constructor code.
Apache Benchmark results with normal ParentHidingHandler:
{quote}
50%272
66%276
75%278
80%281
90%289
95%301
98%493
99%497
{quote}
Results with commented out ParentHidingHandler constructor:
{quote}
50%185
66%188
75%191
80%194
90%202
95%210
98%333
99%338
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-4568) Performance: MergingResourceProvider.ParentHidingHandler adds about 30pp rendering overhead
[
https://issues.apache.org/jira/browse/SLING-4568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14483466#comment-14483466
]
Joel Richard commented on SLING-4568:
-
For some pages the overhead is even bigger. Here we have an example where it is
46pp (87%):
With ParentHidingHandler:
{code}
50%524
66%529
75%536
80%541
90%554
95%617
98%798
99%942
{code}
Without ParentHidingHandler:
{code}
50%280
66%283
75%286
80%288
90%295
95%425
98%454
99%459
{code}
Performance: MergingResourceProvider.ParentHidingHandler adds about 30pp
rendering overhead
---
Key: SLING-4568
URL: https://issues.apache.org/jira/browse/SLING-4568
Project: Sling
Issue Type: Bug
Components: ResourceResolver
Affects Versions: Resource Merger 1.2.8
Reporter: Joel Richard
Priority: Critical
Labels: performance
Attachments: SLING-4568.patch
When I was analysing all read properties, I noticed a recurring pattern with
sling:hideChildren and jcr:primaryType and that more than 40% of the read
properties are sling:hideChildren. I figured out that sling:hideChildren is
read for all parents in MergingResourceProvider.ParentHidingHandler and that
the requests are processed 30-35pp faster just by commenting out the
constructor code.
Apache Benchmark results with normal ParentHidingHandler:
{quote}
50%272
66%276
75%278
80%281
90%289
95%301
98%493
99%497
{quote}
Results with commented out ParentHidingHandler constructor:
{quote}
50%185
66%188
75%191
80%194
90%202
95%210
98%333
99%338
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (SLING-4568) Performance: MergingResourceProvider.ParentHidingHandler adds about 30pp rendering overhead
[
https://issues.apache.org/jira/browse/SLING-4568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14483466#comment-14483466
]
Joel Richard edited comment on SLING-4568 at 4/7/15 4:42 PM:
-
For some pages the overhead is even bigger. Here we have an example where it is
46pp (87%):
With ParentHidingHandler:
{quote}
50%524
66%529
75%536
80%541
90%554
95%617
98%798
99%942
{code}
Without ParentHidingHandler:
{code}
50%280
66%283
75%286
80%288
90%295
95%425
98%454
99%459
{quote}
was (Author: joelrich):
For some pages the overhead is even bigger. Here we have an example where it is
46pp (87%):
With ParentHidingHandler:
{code}
50%524
66%529
75%536
80%541
90%554
95%617
98%798
99%942
{code}
Without ParentHidingHandler:
{code}
50%280
66%283
75%286
80%288
90%295
95%425
98%454
99%459
{code}
Performance: MergingResourceProvider.ParentHidingHandler adds about 30pp
rendering overhead
---
Key: SLING-4568
URL: https://issues.apache.org/jira/browse/SLING-4568
Project: Sling
Issue Type: Bug
Components: ResourceResolver
Affects Versions: Resource Merger 1.2.8
Reporter: Joel Richard
Priority: Critical
Labels: performance
Attachments: SLING-4568.patch
When I was analysing all read properties, I noticed a recurring pattern with
sling:hideChildren and jcr:primaryType and that more than 40% of the read
properties are sling:hideChildren. I figured out that sling:hideChildren is
read for all parents in MergingResourceProvider.ParentHidingHandler and that
the requests are processed 30-35pp faster just by commenting out the
constructor code.
Apache Benchmark results with normal ParentHidingHandler:
{quote}
50%272
66%276
75%278
80%281
90%289
95%301
98%493
99%497
{quote}
Results with commented out ParentHidingHandler constructor:
{quote}
50%185
66%188
75%191
80%194
90%202
95%210
98%333
99%338
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-4568) Performance: MergingResourceProvider.ParentHidingHandler adds about 30pp rendering overhead
[
https://issues.apache.org/jira/browse/SLING-4568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joel Richard updated SLING-4568:
Description:
When I was analysing all read properties, I noticed a recurring pattern with
sling:hideChildren and jcr:primaryType and that more than 40% of the read
properties are sling:hideChildren. I figured out that sling:hideChildren is
read for all parents in MergingResourceProvider.ParentHidingHandler and that
the requests are processed 30-35pp faster just by commenting out the
constructor code.
Apache Benchmark results with normal ParentHidingHandler:
{quote}
50%272
66%276
75%278
80%281
90%289
95%301
98%493
99%497
{quote}
Results with commented out ParentHidingHandler constructor:
{quote}
50%185
66%188
75%191
80%194
90%202
95%210
98%333
99%338
{quote}
was:
When I was analysing all read properties, I noticed a recurring pattern with
sling:hideChildren and jcr:primaryType and that more than 40% of the read
properties are sling:hideChildren. I figured out that sling:hideChildren is
read for all parents in MergingResourceProvider.ParentHidingHandler and that
the requests are processed 30-35% faster just by commenting out the constructor
code.
Apache Benchmark results with normal ParentHidingHandler:
{quote}
50%272
66%276
75%278
80%281
90%289
95%301
98%493
99%497
{quote}
Results with commented out ParentHidingHandler constructor:
{quote}
50%185
66%188
75%191
80%194
90%202
95%210
98%333
99%338
{quote}
Performance: MergingResourceProvider.ParentHidingHandler adds about 30pp
rendering overhead
---
Key: SLING-4568
URL: https://issues.apache.org/jira/browse/SLING-4568
Project: Sling
Issue Type: Bug
Components: ResourceResolver
Affects Versions: Resource Merger 1.2.8
Reporter: Joel Richard
Priority: Critical
Labels: performance
Attachments: SLING-4568.patch
When I was analysing all read properties, I noticed a recurring pattern with
sling:hideChildren and jcr:primaryType and that more than 40% of the read
properties are sling:hideChildren. I figured out that sling:hideChildren is
read for all parents in MergingResourceProvider.ParentHidingHandler and that
the requests are processed 30-35pp faster just by commenting out the
constructor code.
Apache Benchmark results with normal ParentHidingHandler:
{quote}
50%272
66%276
75%278
80%281
90%289
95%301
98%493
99%497
{quote}
Results with commented out ParentHidingHandler constructor:
{quote}
50%185
66%188
75%191
80%194
90%202
95%210
98%333
99%338
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (SLING-4568) Performance: MergingResourceProvider.ParentHidingHandler adds about 30pp rendering overhead
[
https://issues.apache.org/jira/browse/SLING-4568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14483466#comment-14483466
]
Joel Richard edited comment on SLING-4568 at 4/7/15 4:42 PM:
-
For some pages the overhead is even bigger. Here we have an example where it is
46pp (87%):
With ParentHidingHandler:
{quote}
50%524
66%529
75%536
80%541
90%554
95%617
98%798
99%942
{quote}
Without ParentHidingHandler:
{quote}
50%280
66%283
75%286
80%288
90%295
95%425
98%454
99%459
{quote}
was (Author: joelrich):
For some pages the overhead is even bigger. Here we have an example where it is
46pp (87%):
With ParentHidingHandler:
{quote}
50%524
66%529
75%536
80%541
90%554
95%617
98%798
99%942
{code}
Without ParentHidingHandler:
{code}
50%280
66%283
75%286
80%288
90%295
95%425
98%454
99%459
{quote}
Performance: MergingResourceProvider.ParentHidingHandler adds about 30pp
rendering overhead
---
Key: SLING-4568
URL: https://issues.apache.org/jira/browse/SLING-4568
Project: Sling
Issue Type: Bug
Components: ResourceResolver
Affects Versions: Resource Merger 1.2.8
Reporter: Joel Richard
Priority: Critical
Labels: performance
Attachments: SLING-4568.patch
When I was analysing all read properties, I noticed a recurring pattern with
sling:hideChildren and jcr:primaryType and that more than 40% of the read
properties are sling:hideChildren. I figured out that sling:hideChildren is
read for all parents in MergingResourceProvider.ParentHidingHandler and that
the requests are processed 30-35pp faster just by commenting out the
constructor code.
Apache Benchmark results with normal ParentHidingHandler:
{quote}
50%272
66%276
75%278
80%281
90%289
95%301
98%493
99%497
{quote}
Results with commented out ParentHidingHandler constructor:
{quote}
50%185
66%188
75%191
80%194
90%202
95%210
98%333
99%338
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (SLING-4589) Performance: Read properties lazily in MergedValueMap
Joel Richard created SLING-4589: --- Summary: Performance: Read properties lazily in MergedValueMap Key: SLING-4589 URL: https://issues.apache.org/jira/browse/SLING-4589 Project: Sling Issue Type: Improvement Components: ResourceResolver Affects Versions: Resource Merger 1.2.8 Reporter: Joel Richard About 4% of the rendering time is spent in MergedValueMap in ValueMapDecorator.putAll because the JcrPropertyMap has to be read fully before it can be added. Therefore, I would suggest to lazily read the properties in get(key) and merge them there. By the way, in my case 202 of 252 times the MergedValueMap is created only with a single value map. Discussion: http://mail-archives.apache.org/mod_mbox/sling-dev/201504.mbox/%3C5524D90F.7030009%40apache.org%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-4568) Performance: MergingResourceProvider.ParentHidingHandler adds about 30% rendering overhead
Joel Richard created SLING-4568:
---
Summary: Performance: MergingResourceProvider.ParentHidingHandler
adds about 30% rendering overhead
Key: SLING-4568
URL: https://issues.apache.org/jira/browse/SLING-4568
Project: Sling
Issue Type: Bug
Components: ResourceResolver
Affects Versions: Resource Merger 1.2.8
Reporter: Joel Richard
Priority: Critical
When I was analysing all read properties, I have noticed a recurring pattern
with sling:hideChildren and jcr:primaryType and that more than 40% of the read
properties are sling:hideChildren. I figured out that sling:hideChildren is
read for all parents in MergingResourceProvider.ParentHidingHandler and that
the requests are processed 30-35% faster just by uncommenting the constructor
code.
Apache Benchmark results with ParentHidingHandler:
{quote}
50%272
66%276
75%278
80%281
90%289
95%301
98%493
99%497
{quote}
With uncommented ParentHidingHandler:
{quote}
50%185
66%188
75%191
80%194
90%202
95%210
98%333
99%338
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-4568) Performance: MergingResourceProvider.ParentHidingHandler adds about 30% rendering overhead
[
https://issues.apache.org/jira/browse/SLING-4568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joel Richard updated SLING-4568:
Description:
When I was analysing all read properties, I noticed a recurring pattern with
sling:hideChildren and jcr:primaryType and that more than 40% of the read
properties are sling:hideChildren. I figured out that sling:hideChildren is
read for all parents in MergingResourceProvider.ParentHidingHandler and that
the requests are processed 30-35% faster just by commenting out the constructor
code.
Apache Benchmark results with normal ParentHidingHandler:
{quote}
50%272
66%276
75%278
80%281
90%289
95%301
98%493
99%497
{quote}
Results with commented out ParentHidingHandler constructor:
{quote}
50%185
66%188
75%191
80%194
90%202
95%210
98%333
99%338
{quote}
was:
When I was analysing all read properties, I have noticed a recurring pattern
with sling:hideChildren and jcr:primaryType and that more than 40% of the read
properties are sling:hideChildren. I figured out that sling:hideChildren is
read for all parents in MergingResourceProvider.ParentHidingHandler and that
the requests are processed 30-35% faster just by uncommenting the constructor
code.
Apache Benchmark results with ParentHidingHandler:
{quote}
50%272
66%276
75%278
80%281
90%289
95%301
98%493
99%497
{quote}
With uncommented ParentHidingHandler:
{quote}
50%185
66%188
75%191
80%194
90%202
95%210
98%333
99%338
{quote}
Performance: MergingResourceProvider.ParentHidingHandler adds about 30%
rendering overhead
--
Key: SLING-4568
URL: https://issues.apache.org/jira/browse/SLING-4568
Project: Sling
Issue Type: Bug
Components: ResourceResolver
Affects Versions: Resource Merger 1.2.8
Reporter: Joel Richard
Priority: Critical
Labels: performance
When I was analysing all read properties, I noticed a recurring pattern with
sling:hideChildren and jcr:primaryType and that more than 40% of the read
properties are sling:hideChildren. I figured out that sling:hideChildren is
read for all parents in MergingResourceProvider.ParentHidingHandler and that
the requests are processed 30-35% faster just by commenting out the
constructor code.
Apache Benchmark results with normal ParentHidingHandler:
{quote}
50%272
66%276
75%278
80%281
90%289
95%301
98%493
99%497
{quote}
Results with commented out ParentHidingHandler constructor:
{quote}
50%185
66%188
75%191
80%194
90%202
95%210
98%333
99%338
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (SLING-4568) Performance: MergingResourceProvider.ParentHidingHandler adds about 30% rendering overhead
[
https://issues.apache.org/jira/browse/SLING-4568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14392765#comment-14392765
]
Joel Richard edited comment on SLING-4568 at 4/2/15 2:34 PM:
-
By using a simple cache (see attached patch), the overhead can be reduced
drastically:
{quote}
50%198
66%202
75%205
80%206
90%230
95%270
98%337
99%352
{quote}
In addition to the changes in the patch, it could make sense to cache
ancestorChildrenToHideArray separately.
was (Author: joelrich):
By using a simple cache, the overhead can be reduced drastically:
{quote}
50%198
66%202
75%205
80%206
90%230
95%270
98%337
99%352
{quote}
In addition to the changes in the patch, it could make sense to cache
ancestorChildrenToHideArray separately.
Performance: MergingResourceProvider.ParentHidingHandler adds about 30%
rendering overhead
--
Key: SLING-4568
URL: https://issues.apache.org/jira/browse/SLING-4568
Project: Sling
Issue Type: Bug
Components: ResourceResolver
Affects Versions: Resource Merger 1.2.8
Reporter: Joel Richard
Priority: Critical
Labels: performance
Attachments: SLING-4568.patch
When I was analysing all read properties, I noticed a recurring pattern with
sling:hideChildren and jcr:primaryType and that more than 40% of the read
properties are sling:hideChildren. I figured out that sling:hideChildren is
read for all parents in MergingResourceProvider.ParentHidingHandler and that
the requests are processed 30-35% faster just by commenting out the
constructor code.
Apache Benchmark results with normal ParentHidingHandler:
{quote}
50%272
66%276
75%278
80%281
90%289
95%301
98%493
99%497
{quote}
Results with commented out ParentHidingHandler constructor:
{quote}
50%185
66%188
75%191
80%194
90%202
95%210
98%333
99%338
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-4568) Performance: MergingResourceProvider.ParentHidingHandler adds about 30% rendering overhead
[
https://issues.apache.org/jira/browse/SLING-4568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joel Richard updated SLING-4568:
Attachment: SLING-4568.patch
By using a simple cache, the overhead can be reduced drastically:
{quote}
50%198
66%202
75%205
80%206
90%230
95%270
98%337
99%352
{quote}
In addition to the changes in the patch, it could make sense to cache
ancestorChildrenToHideArray separately.
Performance: MergingResourceProvider.ParentHidingHandler adds about 30%
rendering overhead
--
Key: SLING-4568
URL: https://issues.apache.org/jira/browse/SLING-4568
Project: Sling
Issue Type: Bug
Components: ResourceResolver
Affects Versions: Resource Merger 1.2.8
Reporter: Joel Richard
Priority: Critical
Labels: performance
Attachments: SLING-4568.patch
When I was analysing all read properties, I noticed a recurring pattern with
sling:hideChildren and jcr:primaryType and that more than 40% of the read
properties are sling:hideChildren. I figured out that sling:hideChildren is
read for all parents in MergingResourceProvider.ParentHidingHandler and that
the requests are processed 30-35% faster just by commenting out the
constructor code.
Apache Benchmark results with normal ParentHidingHandler:
{quote}
50%272
66%276
75%278
80%281
90%289
95%301
98%493
99%497
{quote}
Results with commented out ParentHidingHandler constructor:
{quote}
50%185
66%188
75%191
80%194
90%202
95%210
98%333
99%338
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (SLING-4596) Performance: Consider optimizing JcrItemResource#getParent and getChild
Joel Richard created SLING-4596: --- Summary: Performance: Consider optimizing JcrItemResource#getParent and getChild Key: SLING-4596 URL: https://issues.apache.org/jira/browse/SLING-4596 Project: Sling Issue Type: Improvement Components: JCR, ResourceResolver Affects Versions: JCR Resource 2.5.0 Reporter: Joel Richard Priority: Critical I have noticed that on some resource intensive pages up to 24% of the rendering time is spent in AbstractResource.getParent. One of the main reasons for this is because the ParentHidingHandler traverses for each resource to the root (see SLING-4568). getParent is not just called often, but is also about 10 times slower than jcrNode.getParent() which has the following reasons: - itemExists is called unnecessary because JcrResourceProvider#createResource does not know that the path belongs to a parent of a node which has already been read. See also SLING-4585. - jcrSession.getItem (which is used to read parents in JcrResourceProvider#createResource) is about 3.5 times slower than jcrNode.getParent in Oak. - Some other overhead which cannot be avoided entirely. The situation could be improved with a getParent implementation which is specific to JcrNodeResource and uses getNode().getParent() directly to create a new JcrNodeResource. I have implemented such a method (see attached experimental patch) and it reduces the time for getParent from 24% to 5% on my test page. As discussed on the [mailing list|http://mail-archives.apache.org/mod_mbox/sling-dev/201504.mbox/%3C55266BB2.1050506%40apache.org%3E] this is not a good solution because the parent resource could be backed by another provider. An alternative approach would be to create a new resource provider interface which accepts the base resource (which is passed to resourceResolver.getResource), retrieves the node form it and uses it for a direct getParent/getNode call (see the linked mail for more information). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4596) Performance: Consider optimizing JcrItemResource#getParent and getChild
[ https://issues.apache.org/jira/browse/SLING-4596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Richard updated SLING-4596: Attachment: JcrNodeResource_getParent.patch Performance: Consider optimizing JcrItemResource#getParent and getChild --- Key: SLING-4596 URL: https://issues.apache.org/jira/browse/SLING-4596 Project: Sling Issue Type: Improvement Components: JCR, ResourceResolver Affects Versions: JCR Resource 2.5.0 Reporter: Joel Richard Priority: Critical Labels: performance Attachments: JcrNodeResource_getParent.patch I have noticed that on some resource intensive pages up to 24% of the rendering time is spent in AbstractResource.getParent. One of the main reasons for this is because the ParentHidingHandler traverses for each resource to the root (see SLING-4568). getParent is not just called often, but is also about 10 times slower than jcrNode.getParent() which has the following reasons: - itemExists is called unnecessary because JcrResourceProvider#createResource does not know that the path belongs to a parent of a node which has already been read. See also SLING-4585. - jcrSession.getItem (which is used to read parents in JcrResourceProvider#createResource) is about 3.5 times slower than jcrNode.getParent in Oak. - Some other overhead which cannot be avoided entirely. The situation could be improved with a getParent implementation which is specific to JcrNodeResource and uses getNode().getParent() directly to create a new JcrNodeResource. I have implemented such a method (see attached experimental patch) and it reduces the time for getParent from 24% to 5% on my test page. As discussed on the [mailing list|http://mail-archives.apache.org/mod_mbox/sling-dev/201504.mbox/%3C55266BB2.1050506%40apache.org%3E] this is not a good solution because the parent resource could be backed by another provider. An alternative approach would be to create a new resource provider interface which accepts the base resource (which is passed to resourceResolver.getResource), retrieves the node form it and uses it for a direct getParent/getNode call (see the linked mail for more information). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-4591) Performance: Consider using a faster empty map in ResourceMetadata#setParameterMap
Joel Richard created SLING-4591: --- Summary: Performance: Consider using a faster empty map in ResourceMetadata#setParameterMap Key: SLING-4591 URL: https://issues.apache.org/jira/browse/SLING-4591 Project: Sling Issue Type: Improvement Components: API Affects Versions: API 2.9.0 Reporter: Joel Richard Priority: Minor ResourceMetadata#setParameterMap is called several thousand times per request. In my case the passed parameterMap is always empty. Since it has to create a new empty LinkedHashMap for each call, 1-2% of the rendering time is spent in this method. Therefore, I would suggest to either ignore empty maps or use Collections.emptyMap() instead. Both solutions should work if the caller does not make any undocumented assumptions for getParameterMap(). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (SLING-4589) Performance: Read properties lazily in MergedValueMap
[ https://issues.apache.org/jira/browse/SLING-4589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Richard resolved SLING-4589. - Resolution: Won't Fix Performance: Read properties lazily in MergedValueMap - Key: SLING-4589 URL: https://issues.apache.org/jira/browse/SLING-4589 Project: Sling Issue Type: Improvement Components: ResourceResolver Affects Versions: Resource Merger 1.2.8 Reporter: Joel Richard Labels: performance Attachments: SLING-4589.txt About 4% of the rendering time is spent in MergedValueMap in ValueMapDecorator.putAll because the JcrPropertyMap has to be read fully before it can be added. Therefore, I would suggest to lazily read the properties in get(key) and merge them there. By the way, in my case 202 of 252 times the MergedValueMap is created only with a single value map. Discussion: http://mail-archives.apache.org/mod_mbox/sling-dev/201504.mbox/%3C5524D90F.7030009%40apache.org%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4589) Performance: Read properties lazily in MergedValueMap
[ https://issues.apache.org/jira/browse/SLING-4589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Richard updated SLING-4589: Attachment: SLING-4589.txt I have tried the attached patch, but unfortunately it didn't help at all because now the time is spent in get() instead of readAll(). For other use cases it could help though. Closing the issue for now because it isn't worth the added complexity. Performance: Read properties lazily in MergedValueMap - Key: SLING-4589 URL: https://issues.apache.org/jira/browse/SLING-4589 Project: Sling Issue Type: Improvement Components: ResourceResolver Affects Versions: Resource Merger 1.2.8 Reporter: Joel Richard Labels: performance Attachments: SLING-4589.txt About 4% of the rendering time is spent in MergedValueMap in ValueMapDecorator.putAll because the JcrPropertyMap has to be read fully before it can be added. Therefore, I would suggest to lazily read the properties in get(key) and merge them there. By the way, in my case 202 of 252 times the MergedValueMap is created only with a single value map. Discussion: http://mail-archives.apache.org/mod_mbox/sling-dev/201504.mbox/%3C5524D90F.7030009%40apache.org%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4584) Performance: XSSAPI.getValidHref should not be based on HTML filtering
[ https://issues.apache.org/jira/browse/SLING-4584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14583456#comment-14583456 ] Joel Richard commented on SLING-4584: - [~radu.cotescu], Antonio has just told me that this is your area and that it would be better if you could have a look at it. Do you have some time for it? By the way, the patch is just so big because I had to copy a config file for the tests. Performance: XSSAPI.getValidHref should not be based on HTML filtering -- Key: SLING-4584 URL: https://issues.apache.org/jira/browse/SLING-4584 Project: Sling Issue Type: Improvement Components: Extensions Affects Versions: XSS Protection API 1.0.2 Reporter: Joel Richard Labels: perfomance, xss Fix For: XSS Protection API 1.0.4 Attachments: 0001-SLING-4584-Performance-XSSAPI.getValidHref-should-no.patch Around 3% of the rendering time is spent in getValidHref because it uses AntiSamy (which is a HTML filter) to do the job. This is obviously a hack and adds a lot of unnecessary overhead. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (SLING-4584) Performance: XSSAPI.getValidHref should not be based on HTML filtering
[ https://issues.apache.org/jira/browse/SLING-4584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14583430#comment-14583430 ] Joel Richard edited comment on SLING-4584 at 6/12/15 2:12 PM: -- [~asanso], would you mind committing the attached patch? It has already been reviewed by [~chaotic]. In my case it improves the overall rendering time by 6%. was (Author: joelrich): [~asanso], would you mind committing the attached patch? It has already been reviewed by [~chaotic]. Performance: XSSAPI.getValidHref should not be based on HTML filtering -- Key: SLING-4584 URL: https://issues.apache.org/jira/browse/SLING-4584 Project: Sling Issue Type: Improvement Components: Extensions Affects Versions: XSS Protection API 1.0.2 Reporter: Joel Richard Labels: perfomance, xss Fix For: XSS Protection API 1.0.4 Attachments: 0001-SLING-4584-Performance-XSSAPI.getValidHref-should-no.patch Around 3% of the rendering time is spent in getValidHref because it uses AntiSamy (which is a HTML filter) to do the job. This is obviously a hack and adds a lot of unnecessary overhead. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4584) Performance: XSSAPI.getValidHref should not be based on HTML filtering
[ https://issues.apache.org/jira/browse/SLING-4584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14583539#comment-14583539 ] Joel Richard commented on SLING-4584: - [~radu.cotescu], that would be great! After discussing it with Lars, we decided to make some changes so it isn't exactly the same anymore. Performance: XSSAPI.getValidHref should not be based on HTML filtering -- Key: SLING-4584 URL: https://issues.apache.org/jira/browse/SLING-4584 Project: Sling Issue Type: Improvement Components: Extensions Affects Versions: XSS Protection API 1.0.2 Reporter: Joel Richard Labels: perfomance, xss Fix For: XSS Protection API 1.0.4 Attachments: 0001-SLING-4584-Performance-XSSAPI.getValidHref-should-no.patch Around 3% of the rendering time is spent in getValidHref because it uses AntiSamy (which is a HTML filter) to do the job. This is obviously a hack and adds a lot of unnecessary overhead. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4584) Performance: XSSAPI.getValidHref should not be based on HTML filtering
[ https://issues.apache.org/jira/browse/SLING-4584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Richard updated SLING-4584: Attachment: 0001-SLING-4584-Performance-XSSAPI.getValidHref-should-no.patch [~asanso], would you mind committing the attached patch? It has already been reviewed by [~chaotic]. Performance: XSSAPI.getValidHref should not be based on HTML filtering -- Key: SLING-4584 URL: https://issues.apache.org/jira/browse/SLING-4584 Project: Sling Issue Type: Improvement Components: Extensions Affects Versions: XSS Protection API 1.0.2 Reporter: Joel Richard Labels: perfomance, xss Fix For: XSS Protection API 1.0.4 Attachments: 0001-SLING-4584-Performance-XSSAPI.getValidHref-should-no.patch Around 3% of the rendering time is spent in getValidHref because it uses AntiSamy (which is a HTML filter) to do the job. This is obviously a hack and adds a lot of unnecessary overhead. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4584) Performance: XSSAPI.getValidHref should not be based on HTML filtering
[ https://issues.apache.org/jira/browse/SLING-4584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Richard updated SLING-4584: Attachment: (was: SLING-4584.patch) Performance: XSSAPI.getValidHref should not be based on HTML filtering -- Key: SLING-4584 URL: https://issues.apache.org/jira/browse/SLING-4584 Project: Sling Issue Type: Improvement Components: Extensions Affects Versions: XSS Protection API 1.0.2 Reporter: Joel Richard Labels: perfomance, xss Fix For: XSS Protection API 1.0.4 Attachments: 0001-SLING-4584-Performance-XSSAPI.getValidHref-should-no.patch Around 3% of the rendering time is spent in getValidHref because it uses AntiSamy (which is a HTML filter) to do the job. This is obviously a hack and adds a lot of unnecessary overhead. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (SLING-4544) Performance: MessageFormat shouldn't be used for logging in SlingRequestProgressTracker
[
https://issues.apache.org/jira/browse/SLING-4544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joel Richard resolved SLING-4544.
-
Resolution: Won't Fix
Closing as won't fix because in comparison to SLING-4596 and SLING-4611 it's
irrelevant and not worth the effort.
Performance: MessageFormat shouldn't be used for logging in
SlingRequestProgressTracker
---
Key: SLING-4544
URL: https://issues.apache.org/jira/browse/SLING-4544
Project: Sling
Issue Type: Improvement
Components: Engine
Affects Versions: Engine 2.4.0
Reporter: Joel Richard
Labels: performance
Attachments: SLING-4544.patch, Screen Shot 2015-03-25 at 10.42.05.png
I am profiling an application where 1-5% of the rendering time is spent in
MessageFormat.format for SlingRequestProgressTracker.log (see attached
screenshot). Since the advanced capabilities of MessageFormat are not
required here, it should be rather easy to implement a utility which supports
\{x} as well but is much faster.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-4585) Performance: Use JackrabbitSession#getItemOrNull to speed up JcrResourceProvider#createResource
[ https://issues.apache.org/jira/browse/SLING-4585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14968773#comment-14968773 ] Joel Richard commented on SLING-4585: - Unfortunately, I have forgotten to increment the API version of the Jackrabbit API which is why we have to wait another release cycle to get this change in (see JCR-3919). The good news is that this change will likely be more effective than anticipated for non-admin users because of the ACL overhead which can be reduced (especially GlobPattern.WildcardPattern in Oak). > Performance: Use JackrabbitSession#getItemOrNull to speed up > JcrResourceProvider#createResource > --- > > Key: SLING-4585 > URL: https://issues.apache.org/jira/browse/SLING-4585 > Project: Sling > Issue Type: Improvement > Components: JCR, ResourceResolver >Affects Versions: JCR Resource 2.5.0 >Reporter: Joel Richard >Priority: Critical > Labels: performance > Attachments: > 0001-SLING-4585-Performance-Use-JackrabbitSession-getItem.patch > > > If the current session is a JackrabbitSession, JcrResourceProvider should use > getItemOrNull (as soon as exported) to save rendering time. > See referenced issue and the following mail thread for more information: > http://mail-archives.apache.org/mod_mbox/jackrabbit-oak-dev/201504.mbox/%3CD1495A09.3B670%25anchela%40adobe.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-5184) JSONRenderer.quote should not use synchronized StringWriter with unspecified length
Joel Richard created SLING-5184: --- Summary: JSONRenderer.quote should not use synchronized StringWriter with unspecified length Key: SLING-5184 URL: https://issues.apache.org/jira/browse/SLING-5184 Project: Sling Issue Type: Improvement Components: Commons Affects Versions: Commons JSON 2.0.12 Reporter: Joel Richard Priority: Minor StringWriter uses a StringBuffer internally which is synchronized. By using a StringBuilder instead and initializing it with the estimated size, this methods becomes 5 times faster (in my real test case). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-5184) JSONRenderer.quote should not use synchronized StringWriter with unspecified length
[ https://issues.apache.org/jira/browse/SLING-5184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14968830#comment-14968830 ] Joel Richard commented on SLING-5184: - Pull request: https://github.com/apache/sling/pull/108 [~rombert], could you please have a look at it? > JSONRenderer.quote should not use synchronized StringWriter with unspecified > length > --- > > Key: SLING-5184 > URL: https://issues.apache.org/jira/browse/SLING-5184 > Project: Sling > Issue Type: Improvement > Components: Commons >Affects Versions: Commons JSON 2.0.12 >Reporter: Joel Richard >Priority: Minor > Labels: json, performance > > StringWriter uses a StringBuffer internally which is synchronized. By using a > StringBuilder instead and initializing it with the estimated size, this > methods becomes 5 times faster (in my real test case). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-5153) MockProperty.isMultiple returns always false
Joel Richard created SLING-5153: --- Summary: MockProperty.isMultiple returns always false Key: SLING-5153 URL: https://issues.apache.org/jira/browse/SLING-5153 Project: Sling Issue Type: Bug Components: Testing Affects Versions: Commons Testing 2.0.18 Reporter: Joel Richard Priority: Minor Fix For: Commons Testing 2.0.20 property.isMultiple() should return the same as property.getDefinition().isMultiple(). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-5152) JsonJcrNode and JsonItemWriter should use prop.isMultiple() instead of def.isMultiple()
Joel Richard created SLING-5152: --- Summary: JsonJcrNode and JsonItemWriter should use prop.isMultiple() instead of def.isMultiple() Key: SLING-5152 URL: https://issues.apache.org/jira/browse/SLING-5152 Project: Sling Issue Type: Improvement Components: Commons Affects Versions: Commons JSON 2.0.12 Reporter: Joel Richard Priority: Minor In Oak, node.getDefinition().isMultiple() is is around 35 times slower than prop.isMultiple(). In addition to this, MockProperty.isMultiple has to be implemented because otherwise the tests fail (for which I will open another issue shortly). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-5152) JsonJcrNode and JsonItemWriter should use prop.isMultiple() instead of def.isMultiple()
[ https://issues.apache.org/jira/browse/SLING-5152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14958918#comment-14958918 ] Joel Richard commented on SLING-5152: - I have created a pull request for this issue and SLING-5153: https://github.com/apache/sling/pull/107 [~rombert] or [~tomek.rekawek], would you mind reviewing the pull request? > JsonJcrNode and JsonItemWriter should use prop.isMultiple() instead of > def.isMultiple() > --- > > Key: SLING-5152 > URL: https://issues.apache.org/jira/browse/SLING-5152 > Project: Sling > Issue Type: Improvement > Components: Commons >Affects Versions: Commons JSON 2.0.12 >Reporter: Joel Richard >Priority: Minor > Labels: json, performance > > In Oak, node.getDefinition().isMultiple() is is around 35 times slower than > prop.isMultiple(). In addition to this, MockProperty.isMultiple has to be > implemented because otherwise the tests fail (for which I will open another > issue shortly). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-5152) JsonJcrNode and JsonItemWriter should use prop.isMultiple() instead of def.isMultiple()
[
https://issues.apache.org/jira/browse/SLING-5152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14958941#comment-14958941
]
Joel Richard commented on SLING-5152:
-
[~rombert], quoting [~anchela] from another conversation:
{quote}Looking at the implementation in Jackrabbit core it have the impression
that in the reference implementation we interpreted this such that
Property.isMultiple returns true if PropertyDefinition.isMultiple returns true.
So, I would take this as de facto standard even if the spec might be a little
bit ambiguous here.{quote}
Since JsonJcrNode/JsonItemWriter operates with the property values, it makes
more sense to use property.isMultiple() anyway in my opinion.
> JsonJcrNode and JsonItemWriter should use prop.isMultiple() instead of
> def.isMultiple()
> ---
>
> Key: SLING-5152
> URL: https://issues.apache.org/jira/browse/SLING-5152
> Project: Sling
> Issue Type: Improvement
> Components: Commons
>Affects Versions: Commons JSON 2.0.12
>Reporter: Joel Richard
>Priority: Minor
> Labels: json, performance
>
> In Oak, node.getDefinition().isMultiple() is is around 35 times slower than
> prop.isMultiple(). In addition to this, MockProperty.isMultiple has to be
> implemented because otherwise the tests fail (for which I will open another
> issue shortly).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Reopened] (SLING-5108) Various little performance improvements
[ https://issues.apache.org/jira/browse/SLING-5108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Richard reopened SLING-5108: - Reopening the issue because I have pushed and will push a few more improvements to the pull request. It's probably better to keep this issue open for a few more days. Sorry for the confusion. > Various little performance improvements > --- > > Key: SLING-5108 > URL: https://issues.apache.org/jira/browse/SLING-5108 > Project: Sling > Issue Type: Improvement > Components: API, Engine, Extensions, JCR, ResourceResolver >Reporter: Joel Richard >Assignee: Tomek Rękawek >Priority: Minor > Labels: performance > Fix For: JCR Resource 2.5.8, API 2.10.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-5117) Reuse PrintWriter to avoid initialisation overhead
[ https://issues.apache.org/jira/browse/SLING-5117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14956786#comment-14956786 ] Joel Richard commented on SLING-5117: - [~cziegeler], do you think the problem could have been the following one? https://bz.apache.org/bugzilla/show_bug.cgi?id=50228 I have already quickly tested the pool and at a first glance it looked fine. Before the PageContext is reused, it resets the internal state of it. Since it resets even the internal state of the JspWriter, it can reuse the same object and therefore we could also reuse the PrintWriter. I don't see a reason why this should be a problem for JSPs/lead to memory leaks (unless there are further bugs similar to #50228). > Reuse PrintWriter to avoid initialisation overhead > -- > > Key: SLING-5117 > URL: https://issues.apache.org/jira/browse/SLING-5117 > Project: Sling > Issue Type: Improvement > Components: Scripting >Reporter: Joel Richard >Priority: Minor > Labels: performance > > Surprisingly, java.io.PrintWriter is relatively expensive to initialise > because of the AccessController.doPrivileged call in the constructor. Right > now, it initialises for each include a new PrintWriter which costs 2-3% > rendering time. > In order to avoid this overhead, I would suggest to fix SLING-1284 properly > (as far as I have seen there is a real fix in Tomcat) and create a reusable > PrintWriter in PageContextImpl together with the JspWriter. In addition, the > OnDemandWriterResponse must be adjusted to not create a new PrintWriter. > Maybe, all the OnDemand* classes could also just be removed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-5108) Various little performance improvements
Joel Richard created SLING-5108: --- Summary: Various little performance improvements Key: SLING-5108 URL: https://issues.apache.org/jira/browse/SLING-5108 Project: Sling Issue Type: Improvement Components: API, Engine, JCR, Scripting Reporter: Joel Richard -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-5108) Various little performance improvements
[ https://issues.apache.org/jira/browse/SLING-5108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14946636#comment-14946636 ] Joel Richard commented on SLING-5108: - First pull request: https://github.com/apache/sling/pull/105 A few other improvements will follow later. > Various little performance improvements > --- > > Key: SLING-5108 > URL: https://issues.apache.org/jira/browse/SLING-5108 > Project: Sling > Issue Type: Improvement > Components: API, Engine, JCR, Scripting >Reporter: Joel Richard > Labels: performance > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4544) Performance: MessageFormat shouldn't be used for logging in SlingRequestProgressTracker
[
https://issues.apache.org/jira/browse/SLING-4544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14945119#comment-14945119
]
Joel Richard commented on SLING-4544:
-
[~tomek.rekawek], I have updated the pull request.
> Performance: MessageFormat shouldn't be used for logging in
> SlingRequestProgressTracker
> ---
>
> Key: SLING-4544
> URL: https://issues.apache.org/jira/browse/SLING-4544
> Project: Sling
> Issue Type: Improvement
> Components: Engine
>Affects Versions: Engine 2.4.0
>Reporter: Joel Richard
>Assignee: Tomek Rękawek
> Labels: performance
> Attachments: SLING-4544.patch, Screen Shot 2015-03-25 at 10.42.05.png
>
>
> I am profiling an application where 1-5% of the rendering time is spent in
> MessageFormat.format for SlingRequestProgressTracker.log (see attached
> screenshot). Since the advanced capabilities of MessageFormat are not
> required here, it should be rather easy to implement a utility which supports
> \{x} as well but is much faster.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-5108) Various little performance improvements
[ https://issues.apache.org/jira/browse/SLING-5108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Richard updated SLING-5108: Component/s: (was: Scripting) > Various little performance improvements > --- > > Key: SLING-5108 > URL: https://issues.apache.org/jira/browse/SLING-5108 > Project: Sling > Issue Type: Improvement > Components: API, Engine, JCR >Reporter: Joel Richard >Assignee: Tomek Rękawek >Priority: Minor > Labels: performance > Fix For: JCR Resource 2.5.8, API 2.10.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-5108) Various little performance improvements
[ https://issues.apache.org/jira/browse/SLING-5108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Richard updated SLING-5108: Priority: Minor (was: Major) > Various little performance improvements > --- > > Key: SLING-5108 > URL: https://issues.apache.org/jira/browse/SLING-5108 > Project: Sling > Issue Type: Improvement > Components: API, Engine, JCR, Scripting >Reporter: Joel Richard >Assignee: Tomek Rękawek >Priority: Minor > Labels: performance > Fix For: JCR Resource 2.5.8, API 2.10.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-5108) Various little performance improvements
[ https://issues.apache.org/jira/browse/SLING-5108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Richard updated SLING-5108: Component/s: ResourceResolver Extensions > Various little performance improvements > --- > > Key: SLING-5108 > URL: https://issues.apache.org/jira/browse/SLING-5108 > Project: Sling > Issue Type: Improvement > Components: API, Engine, Extensions, JCR, ResourceResolver >Reporter: Joel Richard >Assignee: Tomek Rękawek >Priority: Minor > Labels: performance > Fix For: JCR Resource 2.5.8, API 2.10.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-5117) Reuse PrintWriter to avoid initialisation overhead
Joel Richard created SLING-5117: --- Summary: Reuse PrintWriter to avoid initialisation overhead Key: SLING-5117 URL: https://issues.apache.org/jira/browse/SLING-5117 Project: Sling Issue Type: Improvement Components: Scripting Reporter: Joel Richard Priority: Minor Surprisingly, java.io.PrintWriter is relatively expensive to initialise because of the AccessController.doPrivileged call in the constructor. Right now, it initialises for each include a new PrintWriter which costs 2-3% rendering time. In order to avoid this overhead, I would suggest to fix SLING-1284 properly (as far as I have seen there is a real fix in Tomcat) and create a reusable PrintWriter in PageContextImpl together with the JspWriter. In addition, the OnDemandWriterResponse must be adjusted to not create a new PrintWriter. Maybe, all the OnDemand* classes could also just be removed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-5117) Reuse PrintWriter to avoid initialisation overhead
[ https://issues.apache.org/jira/browse/SLING-5117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14947083#comment-14947083 ] Joel Richard commented on SLING-5117: - [~cziegeler], do you remember the details of SLING-1284? When exactly was this an issue? > Reuse PrintWriter to avoid initialisation overhead > -- > > Key: SLING-5117 > URL: https://issues.apache.org/jira/browse/SLING-5117 > Project: Sling > Issue Type: Improvement > Components: Scripting >Reporter: Joel Richard >Priority: Minor > Labels: performance > > Surprisingly, java.io.PrintWriter is relatively expensive to initialise > because of the AccessController.doPrivileged call in the constructor. Right > now, it initialises for each include a new PrintWriter which costs 2-3% > rendering time. > In order to avoid this overhead, I would suggest to fix SLING-1284 properly > (as far as I have seen there is a real fix in Tomcat) and create a reusable > PrintWriter in PageContextImpl together with the JspWriter. In addition, the > OnDemandWriterResponse must be adjusted to not create a new PrintWriter. > Maybe, all the OnDemand* classes could also just be removed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4585) Performance: Use JackrabbitSession#getItemOrNull to speed up JcrResourceProvider#createResource
[ https://issues.apache.org/jira/browse/SLING-4585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Richard updated SLING-4585: Attachment: 0001-SLING-4585-Performance-Use-JackrabbitSession-getItem.patch The attached patch is compatible with the following branch: https://github.com/trekawek/sling/commits/SLING-4750 If we don't have to support older Jackrabbit versions, then we can remove the reflection code again. > Performance: Use JackrabbitSession#getItemOrNull to speed up > JcrResourceProvider#createResource > --- > > Key: SLING-4585 > URL: https://issues.apache.org/jira/browse/SLING-4585 > Project: Sling > Issue Type: Improvement > Components: JCR, ResourceResolver >Affects Versions: JCR Resource 2.5.0 >Reporter: Joel Richard >Priority: Critical > Labels: performance > Attachments: > 0001-SLING-4585-Performance-Use-JackrabbitSession-getItem.patch > > > If the current session is a JackrabbitSession, JcrResourceProvider should use > getItemOrNull (as soon as exported) to save rendering time. > See referenced issue and the following mail thread for more information: > http://mail-archives.apache.org/mod_mbox/jackrabbit-oak-dev/201504.mbox/%3CD1495A09.3B670%25anchela%40adobe.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (SLING-4585) Performance: Use JackrabbitSession#getItemOrNull to speed up JcrResourceProvider#createResource
[ https://issues.apache.org/jira/browse/SLING-4585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Richard reopened SLING-4585: - We cannot implement this as part of SLING-4750 because the latest jackrabbit api hasn't been released. Therefore reopening as discussed with [~tomek.rekawek]. > Performance: Use JackrabbitSession#getItemOrNull to speed up > JcrResourceProvider#createResource > --- > > Key: SLING-4585 > URL: https://issues.apache.org/jira/browse/SLING-4585 > Project: Sling > Issue Type: Improvement > Components: JCR, ResourceResolver >Affects Versions: JCR Resource 2.5.0 >Reporter: Joel Richard >Priority: Critical > Labels: performance > > If the current session is a JackrabbitSession, JcrResourceProvider should use > getItemOrNull (as soon as exported) to save rendering time. > See referenced issue and the following mail thread for more information: > http://mail-archives.apache.org/mod_mbox/jackrabbit-oak-dev/201504.mbox/%3CD1495A09.3B670%25anchela%40adobe.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4585) Performance: Use JackrabbitSession#getItemOrNull to speed up JcrResourceProvider#createResource
[ https://issues.apache.org/jira/browse/SLING-4585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14936604#comment-14936604 ] Joel Richard commented on SLING-4585: - It has to use the latest version for the tests though. There is a TODO in the patch to figure out how to do this. Is it maybe possible to use the latest version with the test scope? > Performance: Use JackrabbitSession#getItemOrNull to speed up > JcrResourceProvider#createResource > --- > > Key: SLING-4585 > URL: https://issues.apache.org/jira/browse/SLING-4585 > Project: Sling > Issue Type: Improvement > Components: JCR, ResourceResolver >Affects Versions: JCR Resource 2.5.0 >Reporter: Joel Richard >Priority: Critical > Labels: performance > Attachments: > 0001-SLING-4585-Performance-Use-JackrabbitSession-getItem.patch > > > If the current session is a JackrabbitSession, JcrResourceProvider should use > getItemOrNull (as soon as exported) to save rendering time. > See referenced issue and the following mail thread for more information: > http://mail-archives.apache.org/mod_mbox/jackrabbit-oak-dev/201504.mbox/%3CD1495A09.3B670%25anchela%40adobe.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4585) Performance: Use JackrabbitSession#getItemOrNull to speed up JcrResourceProvider#createResource
[ https://issues.apache.org/jira/browse/SLING-4585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14936599#comment-14936599 ] Joel Richard commented on SLING-4585: - As long as the changes in the Jackrabbit API/core haven't been released, we cannot commit this change. However, [~tomek.rekawek] wants to proceed with SLING-4750 as quickly as possible and that's why we have decided to reopen this issue. > Performance: Use JackrabbitSession#getItemOrNull to speed up > JcrResourceProvider#createResource > --- > > Key: SLING-4585 > URL: https://issues.apache.org/jira/browse/SLING-4585 > Project: Sling > Issue Type: Improvement > Components: JCR, ResourceResolver >Affects Versions: JCR Resource 2.5.0 >Reporter: Joel Richard >Priority: Critical > Labels: performance > Attachments: > 0001-SLING-4585-Performance-Use-JackrabbitSession-getItem.patch > > > If the current session is a JackrabbitSession, JcrResourceProvider should use > getItemOrNull (as soon as exported) to save rendering time. > See referenced issue and the following mail thread for more information: > http://mail-archives.apache.org/mod_mbox/jackrabbit-oak-dev/201504.mbox/%3CD1495A09.3B670%25anchela%40adobe.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4585) Performance: Use JackrabbitSession#getItemOrNull to speed up JcrResourceProvider#createResource
[
https://issues.apache.org/jira/browse/SLING-4585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14936595#comment-14936595
]
Joel Richard commented on SLING-4585:
-
Sure, I can revert this. I am just a little bit surprised because above you
said:
{quote}We should make sure that the implementation still runs on older
jackrabbit api versions and simply reverts to the old behaviour. Otherwise
updating the jcr resource bundle requires updating the jcr implementation; we
should avoid this{quote}
> Performance: Use JackrabbitSession#getItemOrNull to speed up
> JcrResourceProvider#createResource
> ---
>
> Key: SLING-4585
> URL: https://issues.apache.org/jira/browse/SLING-4585
> Project: Sling
> Issue Type: Improvement
> Components: JCR, ResourceResolver
>Affects Versions: JCR Resource 2.5.0
>Reporter: Joel Richard
>Priority: Critical
> Labels: performance
> Attachments:
> 0001-SLING-4585-Performance-Use-JackrabbitSession-getItem.patch
>
>
> If the current session is a JackrabbitSession, JcrResourceProvider should use
> getItemOrNull (as soon as exported) to save rendering time.
> See referenced issue and the following mail thread for more information:
> http://mail-archives.apache.org/mod_mbox/jackrabbit-oak-dev/201504.mbox/%3CD1495A09.3B670%25anchela%40adobe.com%3E
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-4585) Performance: Use JackrabbitSession#getItemOrNull to speed up JcrResourceProvider#createResource
[ https://issues.apache.org/jira/browse/SLING-4585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14936650#comment-14936650 ] Joel Richard commented on SLING-4585: - [~cziegeler], the tests are intended to ensure that the behaviour between the two ways of retrieving the items is exactly the same. I think they are necessary because the old way, for example, would not have thrown an exception for empty paths while jackrabbitSession.getItemOrNull throws one. Therefore, it needs some special handling to ensure that the behaviour is the same and I think this should have test coverage because otherwise it might happen that somebody will remove the special handling in the future. The snapshot dependencies are not meant to be committed to the Sling code base (which is indicated by the todo above). > Performance: Use JackrabbitSession#getItemOrNull to speed up > JcrResourceProvider#createResource > --- > > Key: SLING-4585 > URL: https://issues.apache.org/jira/browse/SLING-4585 > Project: Sling > Issue Type: Improvement > Components: JCR, ResourceResolver >Affects Versions: JCR Resource 2.5.0 >Reporter: Joel Richard >Priority: Critical > Labels: performance > Attachments: > 0001-SLING-4585-Performance-Use-JackrabbitSession-getItem.patch > > > If the current session is a JackrabbitSession, JcrResourceProvider should use > getItemOrNull (as soon as exported) to save rendering time. > See referenced issue and the following mail thread for more information: > http://mail-archives.apache.org/mod_mbox/jackrabbit-oak-dev/201504.mbox/%3CD1495A09.3B670%25anchela%40adobe.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4585) Performance: Use JackrabbitSession#getItemOrNull to speed up JcrResourceProvider#createResource
[ https://issues.apache.org/jira/browse/SLING-4585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14936812#comment-14936812 ] Joel Richard commented on SLING-4585: - Right, we have to wait until Jackrabbit/Oak has been released with the getItemOrNull changes (should be done in 2 weeks if I remember correctly). > Performance: Use JackrabbitSession#getItemOrNull to speed up > JcrResourceProvider#createResource > --- > > Key: SLING-4585 > URL: https://issues.apache.org/jira/browse/SLING-4585 > Project: Sling > Issue Type: Improvement > Components: JCR, ResourceResolver >Affects Versions: JCR Resource 2.5.0 >Reporter: Joel Richard >Priority: Critical > Labels: performance > Attachments: > 0001-SLING-4585-Performance-Use-JackrabbitSession-getItem.patch > > > If the current session is a JackrabbitSession, JcrResourceProvider should use > getItemOrNull (as soon as exported) to save rendering time. > See referenced issue and the following mail thread for more information: > http://mail-archives.apache.org/mod_mbox/jackrabbit-oak-dev/201504.mbox/%3CD1495A09.3B670%25anchela%40adobe.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (SLING-4544) Performance: MessageFormat shouldn't be used for logging in SlingRequestProgressTracker
[
https://issues.apache.org/jira/browse/SLING-4544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joel Richard reopened SLING-4544:
-
I encountered a page where 6.7% of the rendering time is spent in
MessageFormat.format and decided to implement a faster MessageFormat
implementation anyway. It's kept very simple and falls back to the original
implementation for more complex formats. This change reduces the overhead to
3.5% (which is mainly due to toString methods).
The pull request can be found here: https://github.com/apache/sling/pull/104
[~tomek.rekawek], would you mind reviewing it?
> Performance: MessageFormat shouldn't be used for logging in
> SlingRequestProgressTracker
> ---
>
> Key: SLING-4544
> URL: https://issues.apache.org/jira/browse/SLING-4544
> Project: Sling
> Issue Type: Improvement
> Components: Engine
>Affects Versions: Engine 2.4.0
>Reporter: Joel Richard
> Labels: performance
> Attachments: SLING-4544.patch, Screen Shot 2015-03-25 at 10.42.05.png
>
>
> I am profiling an application where 1-5% of the rendering time is spent in
> MessageFormat.format for SlingRequestProgressTracker.log (see attached
> screenshot). Since the advanced capabilities of MessageFormat are not
> required here, it should be rather easy to implement a utility which supports
> \{x} as well but is much faster.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-4611) Performance: Consider optimizing MergedResource#getParent and getChild
[ https://issues.apache.org/jira/browse/SLING-4611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14943495#comment-14943495 ] Joel Richard commented on SLING-4611: - I have created a pull request which is compatible with the latest resource provider API: https://github.com/trekawek/sling/pull/2 > Performance: Consider optimizing MergedResource#getParent and getChild > -- > > Key: SLING-4611 > URL: https://issues.apache.org/jira/browse/SLING-4611 > Project: Sling > Issue Type: Improvement > Components: ResourceResolver >Affects Versions: Resource Merger 1.2.8 >Reporter: Joel Richard >Priority: Critical > Labels: perfomance > Attachments: SLING-4611_experimental.patch > > > For some pages up to 29% of the rendering time is spent in > AbstractResource.getChild. In my case, 75% of the resources are > MergedResources and the rest are JcrNodeResources (for which I have already > opened SLING-4596). > Therefore, I would suggest implementing the following optimization: > The merged resources should be stored in MergedResource and when getChild is > called, it would use getChild on them directly and merge the child resources. > This would have the advantage that the ParentHidingHandler would not have to > be called again for the parent resources and could even make SLING-4568 > obsolete. Moreover, it would leverage optimizations of the merged resource > implementations (e.g. SLING-4596 for JcrNodeResource#getChild). > A problem with this approach is that possible in JCR (and maybe also some > other resource providers) to set ACLs which allow to read children but not > their parents. Therefore, getChild will in addition have to check for each > search path which isn't covered with a merged resource if this path does > really not exist. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4585) Performance: Use JackrabbitSession#getItemOrNull to speed up JcrResourceProvider#createResource
[ https://issues.apache.org/jira/browse/SLING-4585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Richard updated SLING-4585: Attachment: (was: 0001-SLING-4585-Performance-Use-JackrabbitSession-getItem.patch) > Performance: Use JackrabbitSession#getItemOrNull to speed up > JcrResourceProvider#createResource > --- > > Key: SLING-4585 > URL: https://issues.apache.org/jira/browse/SLING-4585 > Project: Sling > Issue Type: Improvement > Components: JCR, ResourceResolver >Affects Versions: JCR Resource 2.5.0 >Reporter: Joel Richard >Priority: Critical > Labels: performance > Fix For: JCR Resource 2.6.0 > > > If the current session is a JackrabbitSession, JcrResourceProvider should use > getItemOrNull (as soon as exported) to save rendering time. > See referenced issue and the following mail thread for more information: > http://mail-archives.apache.org/mod_mbox/jackrabbit-oak-dev/201504.mbox/%3CD1495A09.3B670%25anchela%40adobe.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4585) Performance: Use JackrabbitSession#getItemOrNull to speed up JcrResourceProvider#createResource
[ https://issues.apache.org/jira/browse/SLING-4585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Richard updated SLING-4585: Attachment: 0001-SLING-4585-Performance-Use-JackrabbitSession-getItem.patch I have just attached an updated patch for trunk. Because of the Jackrabbit/Oak update, I had to adjust two unrelated tests. Since commons.testing hasn't been released (see SLING-5341), I had to add a dependency to jackrabbit-core. Ideally, this patch is only applied after commons.testing has been released and then the jackrabbit-core dependency can be removed again. Please note that this change breaks compatibility with older Jackrabbit and Oak versions. Carsten has agreed with this change. [~rombert], would you mind taking care of the patch and this issue? > Performance: Use JackrabbitSession#getItemOrNull to speed up > JcrResourceProvider#createResource > --- > > Key: SLING-4585 > URL: https://issues.apache.org/jira/browse/SLING-4585 > Project: Sling > Issue Type: Improvement > Components: JCR, ResourceResolver >Affects Versions: JCR Resource 2.5.0 >Reporter: Joel Richard >Priority: Critical > Labels: performance > Fix For: JCR Resource 2.6.0 > > Attachments: > 0001-SLING-4585-Performance-Use-JackrabbitSession-getItem.patch > > > If the current session is a JackrabbitSession, JcrResourceProvider should use > getItemOrNull (as soon as exported) to save rendering time. > See referenced issue and the following mail thread for more information: > http://mail-archives.apache.org/mod_mbox/jackrabbit-oak-dev/201504.mbox/%3CD1495A09.3B670%25anchela%40adobe.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-5108) Various little performance improvements
[ https://issues.apache.org/jira/browse/SLING-5108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15050408#comment-15050408 ] Joel Richard commented on SLING-5108: - [~cziegeler], I have completed the fix versions. This issue can be closed now. Would be nice if the changed bundles could be released soon. > Various little performance improvements > --- > > Key: SLING-5108 > URL: https://issues.apache.org/jira/browse/SLING-5108 > Project: Sling > Issue Type: Improvement > Components: API, Engine, Extensions, JCR, ResourceResolver >Reporter: Joel Richard >Assignee: Tomek Rękawek >Priority: Minor > Labels: performance > Fix For: Servlets Resolver 2.3.10, JCR Resource 2.6.0, API > 2.10.0, Resource Resolver 1.3.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-5108) Various little performance improvements
[ https://issues.apache.org/jira/browse/SLING-5108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Richard updated SLING-5108: Fix Version/s: Resource Resolver 1.3.0 Servlets Resolver 2.3.10 > Various little performance improvements > --- > > Key: SLING-5108 > URL: https://issues.apache.org/jira/browse/SLING-5108 > Project: Sling > Issue Type: Improvement > Components: API, Engine, Extensions, JCR, ResourceResolver >Reporter: Joel Richard >Assignee: Tomek Rękawek >Priority: Minor > Labels: performance > Fix For: Servlets Resolver 2.3.10, JCR Resource 2.6.0, API > 2.10.0, Resource Resolver 1.3.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-5341) Update Jackrabbit in Commons Testing to 2.11.2
[
https://issues.apache.org/jira/browse/SLING-5341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15033251#comment-15033251
]
Joel Richard commented on SLING-5341:
-
[~olli], thank you. Is there already a release scheduled for it?
> Update Jackrabbit in Commons Testing to 2.11.2
> --
>
> Key: SLING-5341
> URL: https://issues.apache.org/jira/browse/SLING-5341
> Project: Sling
> Issue Type: Task
> Components: Testing
>Affects Versions: Commons Testing 2.0.22
>Reporter: Joel Richard
>Assignee: Oliver Lietz
>
> For SLING-4585 we have to use the latest jackrabbit-core version (2.11.2).
> Otherwise the tests fail with the following error:
> {code}java.lang.AbstractMethodError:
> org.apache.jackrabbit.core.XASessionImpl.getItemOrNull(Ljava/lang/String;)Ljavax/jcr/Item;
> at
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrItemResourceFactory.getItemOrNull(JcrItemResourceFactory.java:182){code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (SLING-5341) Update jackrabbit version of commons.testing
Joel Richard created SLING-5341:
---
Summary: Update jackrabbit version of commons.testing
Key: SLING-5341
URL: https://issues.apache.org/jira/browse/SLING-5341
Project: Sling
Issue Type: Task
Components: Testing
Affects Versions: Commons Testing 2.0.22
Reporter: Joel Richard
For SLING-4585 we have to use the latest jackrabbit-core version (2.11.2).
Otherwise the tests fail with the following error:
{code}java.lang.AbstractMethodError:
org.apache.jackrabbit.core.XASessionImpl.getItemOrNull(Ljava/lang/String;)Ljavax/jcr/Item;
at
org.apache.sling.jcr.resource.internal.helper.jcr.JcrItemResourceFactory.getItemOrNull(JcrItemResourceFactory.java:182){code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-5341) Update jackrabbit version in commons.testing
[
https://issues.apache.org/jira/browse/SLING-5341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joel Richard updated SLING-5341:
Summary: Update jackrabbit version in commons.testing (was: Update
jackrabbit version of commons.testing)
> Update jackrabbit version in commons.testing
>
>
> Key: SLING-5341
> URL: https://issues.apache.org/jira/browse/SLING-5341
> Project: Sling
> Issue Type: Task
> Components: Testing
>Affects Versions: Commons Testing 2.0.22
>Reporter: Joel Richard
>
> For SLING-4585 we have to use the latest jackrabbit-core version (2.11.2).
> Otherwise the tests fail with the following error:
> {code}java.lang.AbstractMethodError:
> org.apache.jackrabbit.core.XASessionImpl.getItemOrNull(Ljava/lang/String;)Ljavax/jcr/Item;
> at
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrItemResourceFactory.getItemOrNull(JcrItemResourceFactory.java:182){code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-5341) Update jackrabbit version in commons.testing
[
https://issues.apache.org/jira/browse/SLING-5341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15031713#comment-15031713
]
Joel Richard commented on SLING-5341:
-
[~rombert], could you please have a look at the pull request?
> Update jackrabbit version in commons.testing
>
>
> Key: SLING-5341
> URL: https://issues.apache.org/jira/browse/SLING-5341
> Project: Sling
> Issue Type: Task
> Components: Testing
>Affects Versions: Commons Testing 2.0.22
>Reporter: Joel Richard
>
> For SLING-4585 we have to use the latest jackrabbit-core version (2.11.2).
> Otherwise the tests fail with the following error:
> {code}java.lang.AbstractMethodError:
> org.apache.jackrabbit.core.XASessionImpl.getItemOrNull(Ljava/lang/String;)Ljavax/jcr/Item;
> at
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrItemResourceFactory.getItemOrNull(JcrItemResourceFactory.java:182){code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (SLING-5501) Adjust resource merger for latest API changes
Joel Richard created SLING-5501: --- Summary: Adjust resource merger for latest API changes Key: SLING-5501 URL: https://issues.apache.org/jira/browse/SLING-5501 Project: Sling Issue Type: Bug Components: ResourceResolver Affects Versions: Resource Merger 1.2.10 Reporter: Joel Richard Fix For: Resource Merger 1.2.12 This is a follow up issue for SLING-4611. The resource merger code has to be adjusted for the latest resource provider changes. I will attach a patch shortly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-5501) Adjust resource merger for latest API changes
[ https://issues.apache.org/jira/browse/SLING-5501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Richard updated SLING-5501: Attachment: SLING-5501.patch > Adjust resource merger for latest API changes > - > > Key: SLING-5501 > URL: https://issues.apache.org/jira/browse/SLING-5501 > Project: Sling > Issue Type: Bug > Components: ResourceResolver >Affects Versions: Resource Merger 1.2.10 >Reporter: Joel Richard > Labels: performance > Fix For: Resource Merger 1.2.12 > > Attachments: SLING-5501.patch > > > This is a follow up issue for SLING-4611. The resource merger code has to be > adjusted for the latest resource provider changes. I will attach a patch > shortly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-5463) GetStarTest fails with "Invalid name or path"
[
https://issues.apache.org/jira/browse/SLING-5463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15121720#comment-15121720
]
Joel Richard commented on SLING-5463:
-
[~rombert], the reason is that createResource has returned null so far when a
path was invalid. I tried to keep this behaviour, but it seems like I missed
some cases. I am having a closer look at it right now.
> GetStarTest fails with "Invalid name or path"
> -
>
> Key: SLING-5463
> URL: https://issues.apache.org/jira/browse/SLING-5463
> Project: Sling
> Issue Type: Bug
> Components: Testing
>Reporter: Bertrand Delacretaz
>Assignee: Robert Munteanu
>Priority: Minor
> Labels: sling-IT
>
> The GetStarTest from launchpad/integration-tests recently started failing,
> for example at [1]:
> {code}
> javax.jcr.RepositoryException: Invalid name or path:
> /GetStarTest1453972215267/*
> at
> org.apache.jackrabbit.oak.jcr.session.SessionContext.getOakPathOrThrow(SessionContext.java:347)
> ...
> at
> org.apache.jackrabbit.oak.jcr.session.SessionImpl.getItemOrNull(SessionImpl.java:225)
> at
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrItemResourceFactory.getItemOrNull(JcrItemResourceFactory.java:182)
> at
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrItemResourceFactory.createResource(JcrItemResourceFactory.java:96)
> at
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.listChildren(JcrResourceProvider.java:293)
> at
> org.apache.sling.resourceresolver.impl.providers.stateful.AuthenticatedResourceProvider.listChildren(AuthenticatedResourceProvider.java:175)
> at
> org.apache.sling.resourceresolver.impl.providers.stateful.CombinedResourceProvider.listChildren(CombinedResourceProvider.java:205)
> at
> org.apache.sling.resourceresolver.impl.ResourceResolverImpl.listChildren(ResourceResolverImpl.java:719)
> at
> org.apache.sling.api.resource.ResourceUtil.listChildren(ResourceUtil.java:360)
> ...
> at
> org.apache.sling.servlets.get.impl.helpers.JsonRendererServlet.doGet(JsonRendererServlet.java:100)
> {code}
> [1]
> https://builds.apache.org/view/S-Z/view/Sling/job/sling-trunk-1.7/org.apache.sling$org.apache.sling.launchpad.testing/3252/testReport/junit/org.apache.sling.launchpad.webapp.integrationtest/GetStarTest/testGetStarJson/
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
