[jira] [Commented] (SLING-2311) Sling Performance Testing tool
[ https://issues.apache.org/jira/browse/SLING-2311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13242306#comment-13242306 ] Antonio Sanso commented on SLING-2311: -- IMHO junit-perf is cool, point is that sometimes is not enough to decorate a unit test since you need to create a specific 'scenario' e.g.for SLING-2255 the prerequisite was to have an high number of vanity paths. About a new module as said this is a 'porting' of something already existing in jackrabbit and I have tried to maintain the original idea just adapting a bit the framework to be more bundle version friendly rather than release based. An example of a potential outcome is in [0]. [0] https://issues.apache.org/jira/secure/attachment/12520603/ResolveWithManyVanityPath.png > Sling Performance Testing tool > -- > > Key: SLING-2311 > URL: https://issues.apache.org/jira/browse/SLING-2311 > Project: Sling > Issue Type: New Feature > Components: Testing >Reporter: Antonio Sanso >Assignee: Carsten Ziegeler >Priority: Minor > Attachments: ResolveWithManyAliasTest.java, > ResolveWithManyVanityPath.png, SLING-2311-patch.txt > > > As described/discussed in [0] it would be nice to have a performance test > tool in Sling . > This can be useful in different situations (e.g. micro benchmarks of a > feature and so on). > Patch to follow > [0] http://sling.markmail.org/message/bz44im7aqeae4r57 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-2255) Improve JcrResourceResolver#resolve performance when big number of vanityPath are present
[ https://issues.apache.org/jira/browse/SLING-2255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13238379#comment-13238379 ] Antonio Sanso commented on SLING-2255: -- Great work Carsten. I have ran the tests in SLING-2311 and this confirm the magnitude of the improvement. This is the outcome before the patch (in ms) # ResolveWithManyVanityPathTest min 10% 50% 90% max jcr.resource-2.0.11 56 57 60 120 406 and after the patch # ResolveWithManyVanityPathTest min 10% 50% 90% max jcr.resource-2.0.11 12 13 15 19 401 > Improve JcrResourceResolver#resolve performance when big number of vanityPath > are present > - > > Key: SLING-2255 > URL: https://issues.apache.org/jira/browse/SLING-2255 > Project: Sling > Issue Type: Improvement > Components: JCR >Affects Versions: JCR Resource 2.0.10 >Reporter: Antonio Sanso >Assignee: Carsten Ziegeler >Priority: Minor > Fix For: JCR Resource 2.1.0 > > Attachments: SLING-2255.txt, performance.pdf > > > At the moment the performance of JcrResourceResolver#resolve is tight with > the number of sling:vanityPath present in the repository. > Large number of vanityPath means large response time specially in the worse > case scenario (namely huge number of vanityPath and request that doesn't > match any vanityPath) but also in the average cases. > Sling currently employs generic regexps also for vanityPath, but since the > regex behind a vanityPath is well know there is room for optimization. > I'll attach a graphs that shows the situation and a potential patch. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-2136) Sling POST Servlet: Configuration of Allowed Paths
[ https://issues.apache.org/jira/browse/SLING-2136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13186853#comment-13186853 ] Antonio Sanso commented on SLING-2136: -- "Now, as long as the node /bin/replicate exists... the ReplicationServlet will not be executed for requests to /bin/replicate. This presents a problem and explains the necessity for this feature." Just for reference, I think the new new startup filter SLING-2347 might help here > Sling POST Servlet: Configuration of Allowed Paths > -- > > Key: SLING-2136 > URL: https://issues.apache.org/jira/browse/SLING-2136 > Project: Sling > Issue Type: Improvement > Components: Servlets >Affects Versions: Servlets Post 2.1.2 >Reporter: Andrew Khoury > Attachments: post_servlet_filter-1205238.patch > > > It would be nice if you could configure rules or regular expressions for > paths the sling post servlet is allowed to work under. This would be good > for both security reasons and for protecting against conflicts with other > servlets. > For example: > Let's say you have a servlet ReplicationServlet registered to receive POST > requests under path /bin/replicate. > However, during startup, before the ReplicationServlet component has been > enabled, a user tries to do a POST to /bin/replicate. In this case, instead > of executing the ReplicationServlet, the POST servlet is executed and it > creates a node under /bin/replicate. Now, as long as the node /bin/replicate > exists... the ReplicationServlet will not be executed for requests to > /bin/replicate. This presents a problem and explains the necessity for this > feature. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-2251) RedirectServlet should create relative Location headers as often as possible
[
https://issues.apache.org/jira/browse/SLING-2251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13168404#comment-13168404
]
Antonio Sanso commented on SLING-2251:
--
+1
> RedirectServlet should create relative Location headers as often as possible
>
>
> Key: SLING-2251
> URL: https://issues.apache.org/jira/browse/SLING-2251
> Project: Sling
> Issue Type: Improvement
> Components: Servlets
>Affects Versions: Servlets Get 2.1.2
>Reporter: Alexander Klimetschek
> Attachments: SLING-2251-VanityPathTest.patch, SLING-2251.patch
>
>
> SLING-1965 (more specifically
> http://svn.apache.org/viewvc?view=revision&revision=903175 ) changed the
> redirect servlet so that it _always_ generates an absolute location header.
> The issue does not give much reasoning for that.
> The problem is that this breaks cases where a Sling server is run behind a
> proxy (which does not or cannot rewrite the Location header), as the redirect
> ("http://localhost:8080/some/path";) might not match the externally visible
> domain (e.g. "https://my.domain.com";). Also, the schema is fixed (e.g. might
> switch external https back to http).
> A solution would be to generate absolute URLs only if a resource resolver
> mapping (/etc/map) includes an explicit domain and thus generates an absolute
> URL. For all other cases, relative URLs should be generated. AFAICS, this was
> the case before SLING-1965.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-2156) Provide error handling for POST operations
[ https://issues.apache.org/jira/browse/SLING-2156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13163581#comment-13163581 ] Antonio Sanso commented on SLING-2156: -- Hi Ben, Justin patch has been already committed as for SLING-2223. This ticket might be complementary to that. > Provide error handling for POST operations > -- > > Key: SLING-2156 > URL: https://issues.apache.org/jira/browse/SLING-2156 > Project: Sling > Issue Type: New Feature > Components: Servlets >Reporter: Antonio Sanso > Attachments: SLING-2156-patch.txt, SLING-2156-patch.txt, > SLING-2156-patch.txt, SLING-2156-patch.txt, post_error_handling > > > The error handling mechanism described here [0] doesn't seem to apply also to > POST operations. > If an error occurs while posting a resource to repository (e.g. > avax.jcr.nodetype.ConstraintViolationException: no matching property > definition found for) the HtmlResponse.html template is rendered. > This can also represent a security issue since information as > REFERRER/technology stack are shown. > IMHO this page should be at least configurable (if the mechanism in [0] > doesn't suite here). > [0] http://sling.apache.org/site/errorhandling.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-2314) FSResourcerProvider: Use SCR Java Annotations
[ https://issues.apache.org/jira/browse/SLING-2314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13161565#comment-13161565 ] Antonio Sanso commented on SLING-2314: -- Hi Stefan, FYI also note that Justin created a general issue for this back in September: https://issues.apache.org/jira/browse/SLING-2209 > FSResourcerProvider: Use SCR Java Annotations > - > > Key: SLING-2314 > URL: https://issues.apache.org/jira/browse/SLING-2314 > Project: Sling > Issue Type: Improvement > Components: Extensions >Affects Versions: File System Resource Provider 1.0.2 >Reporter: Stefan Seifert >Priority: Minor > Attachments: 111202_SLING-2314_fsresource_annotations.patch > > > the FSResourceProvider should use SCR java annotations instead of the javadoc > annotations (which will be deprecated soon). > Patch attached. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-2255) Improve JcrResourceResolver#resolve performance when big number of vanityPath are present
[
https://issues.apache.org/jira/browse/SLING-2255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13154236#comment-13154236
]
Antonio Sanso commented on SLING-2255:
--
Thanks a lot for your comment Carsten.
Yes this
if
(this.factory.getMapEntries().getVanityMaps().containsKey(getPathVanityKey(absPath))){
is supposed to be by "design" in order to match with
..
vanityMaps.put(pVanityPath,entries);
..
I have spot a bug in the #getPathVanityKey method though but can be easily
corrected...
Moreover since I have created the patch I have noticed that this could be
further optimized
This
if
(this.factory.getMapEntries().getVanityMaps().containsKey(getPathVanityKey(absPath))){
for (MapEntry mapEntry :
this.factory.getMapEntries().getResolveVanityMaps()) {
could be replaced with
if
(this.factory.getMapEntries().getVanityMaps().containsKey(getPathVanityKey(absPath))){
MapEntry mapEntry=
this.factory.getMapEntries().getResolveVanityMaps().get(getPathVanityKey(absPath))
avoiding the loop.
Overall I do agree with your comments. The best approach would be a complete
redesign in order to have a more clean approach.
About the two different maps I am not sure if you have noticed that the
semantic for the #getResolveMaps method is the same since it merges and sorts
the two maps.
As you said though this is really in the heart of Sling and any change here
should be done really carefully. A more extensive test coverage might help here
(but I must say the existing one for this area is pretty good).
> Improve JcrResourceResolver#resolve performance when big number of vanityPath
> are present
> -
>
> Key: SLING-2255
> URL: https://issues.apache.org/jira/browse/SLING-2255
> Project: Sling
> Issue Type: Improvement
> Components: JCR
>Affects Versions: JCR Resource 2.0.10
>Reporter: Antonio Sanso
>Assignee: Carsten Ziegeler
>Priority: Minor
> Fix For: JCR Resource 2.1.0
>
> Attachments: SLING-2255.txt, performance.pdf
>
>
> At the moment the performance of JcrResourceResolver#resolve is tight with
> the number of sling:vanityPath present in the repository.
> Large number of vanityPath means large response time specially in the worse
> case scenario (namely huge number of vanityPath and request that doesn't
> match any vanityPath) but also in the average cases.
> Sling currently employs generic regexps also for vanityPath, but since the
> regex behind a vanityPath is well know there is room for optimization.
> I'll attach a graphs that shows the situation and a potential patch.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-2246) Wrong mapping for nodes having sling:alias property
[ https://issues.apache.org/jira/browse/SLING-2246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13128503#comment-13128503 ] Antonio Sanso commented on SLING-2246: -- I have spotted a little issue in the patch hence I have deleted it. I'll attach soon a revised one > Wrong mapping for nodes having sling:alias property > --- > > Key: SLING-2246 > URL: https://issues.apache.org/jira/browse/SLING-2246 > Project: Sling > Issue Type: Bug > Components: JCR >Reporter: Antonio Sanso > > Step to reproduce the issue: > - suppose you have a node having path /test > - add node jcr:content > - add property sling:alias with value testAlias to the /test/jcr:content node > - call resolve#map for /test/jcr:content node > expected result: /testAlias/_jcr_content > actual result: /testAlias/testAlias > patch to follow -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-2246) Wrong mapping for nodes having sling:alias property
[ https://issues.apache.org/jira/browse/SLING-2246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13127605#comment-13127605 ] Antonio Sanso commented on SLING-2246: -- both the issue and the patch are based on the assumption that the jcr:content node cannot have an alias . Can this assumption considered correct? Should be the case I will also attach a patch containing more junit test for JcrResourceResolverTest #testResolveResourceAliasJcrContent covering the map cases. For sure though having as result /testAlias/testAlias sounds wrong. > Wrong mapping for nodes having sling:alias property > --- > > Key: SLING-2246 > URL: https://issues.apache.org/jira/browse/SLING-2246 > Project: Sling > Issue Type: Bug > Components: JCR >Reporter: Antonio Sanso > Attachments: SLING-2246-asanso-patch.txt > > > Step to reproduce the issue: > - suppose you have a node having path /test > - add node jcr:content > - add property sling:alias with value testAlias to the /test/jcr:content node > - call resolve#map for /test/jcr:content node > expected result: /testAlias/_jcr_content > actual result: /testAlias/testAlias > patch to follow -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
