cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jean-Baptiste Quenot (JIRA)" <>
Subject [jira] Commented: (COCOON-1709) Speedup portal loading
Date Mon, 02 Jan 2006 17:32:01 GMT
    [ ] 

Jean-Baptiste Quenot commented on COCOON-1709:

I understand your concerns about scalability.  However, your comment is only relevant when
a lot of profiles are defined, eg profiles/copletdata/portal-0001.xml, profiles/copletdata/portal-0002.xml
upto profiles/copletdata/portal-9999.xml.  In our case, all users use the same profile: profiles/copletdata/portal.xml.

However, I believe that in most cases, the profiles are loaded with a pipeline, and unfortunately
SitemapSource.getURI() returns the URL with a query string like eg load-role-profile?user=user-1299,
which will then produce a lot of copies in memory indeed, because we use source.getURI() as
key and not the requested source itself.  In our case, we use a source that returns the real
file location, so that source.getURI() returns very few different results: portal-user-admin.xml,
portal-role-public.xml, or portal.xml.

Please find attached my portal configuration for profiles, and the UserRoleSource used for
resolving them.

> Speedup portal loading
> ----------------------
>          Key: COCOON-1709
>          URL:
>      Project: Cocoon
>         Type: Improvement
>   Components: Blocks: Portal
>     Versions: 2.1.9-dev (current SVN)
>     Reporter: Jean-Baptiste Quenot
>  Attachments: 20051212-portal-MapProfileLS,,,
> Portal loads user profiles (when using eg AuthenticationProfileManager) with Castor every
time the user logs in and this is very slow.  This patch allows to cache the result for further
invocations.  However the coplet instance profiles are handled in a special way, after being
obtained by mapping the CopletInstanceDataManager they are cloned to ensure that every user
gets its own copy of the coplets.  Thus this bug depends on
Allow CopletInstanceDataManager to be cloneable.
> An improvement would be to store cached objects in Cocoon Store, the provided patch currently
uses a simple HashMap to store profiles.  Note that the key of the object is the URI returned
by the source.  This is important because different values of uri in resolver.resolveURI(uri)
could return the same source, ie source.getURI() could be the same, so only different objects
are stored in the Map.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message