[
https://issues.apache.org/jira/browse/SLING-3290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14084584#comment-14084584
]
Felix Meschberger commented on SLING-3290:
------------------------------------------
bq. Did you "follow" the update of MapEntries done in SLING-3505. The
full-work-on-update is not there anymore
Perfect.
bq. About the /etc/map the things that doesn't make me eager of this solution
is the full duplication of the content (namely the same information is
maintained completely in two location) and the problem to keep those on sync.
E.g. what would happen if I manually delete one vanity path entry from etc/map
:S ?
Yes, there is duplication. But we can "solve" that dilemma in that we declare
the {{/etc/map}} content as being the canonical content and the
sling:vanityPath properties spread around the content to be "hints". As I said
vanity paths are really special and should be treated with extreme care. And so
IMHO it is perfectly valid to make it harder to manage them and to be able to
impose processes to update vanity paths. Also {{/etc/map}} is (or should be)
locked down, so that it cannot easily be tampered with.
> Long startup time with many vanityPath
> --------------------------------------
>
> Key: SLING-3290
> URL: https://issues.apache.org/jira/browse/SLING-3290
> Project: Sling
> Issue Type: Improvement
> Components: ResourceResolver
> Reporter: Antonio Sanso
> Assignee: Antonio Sanso
> Labels: vanity
> Attachments: SLING-3290-patch.txt, StartupWithManyVanityPath.jpg
>
>
> When many vanityPath or alias are present the system take long time to
> startup , Same when a vanityPath/alias is removed or updated .
> The reason behind is the usage of a query that updates the global mapentry.
> I have added a new Test to the performance test suite and this is the outcome
> {code}
> 0 vanityPath 16ms
> 1 vanityPath 19ms
> 10 vanityPath 70ms
> 100 vanityPath 111ms
> 1000 vanityPath 200ms
> 10000 vanityPath 1173ms
> 30000 vanityPath 3358ms
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
