[ http://issues.apache.org/jira/browse/COCOON-1709?page=comments#action_12361536 ]
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: http://issues.apache.org/jira/browse/COCOON-1709 > Project: Cocoon > Type: Improvement > Components: Blocks: Portal > Versions: 2.1.9-dev (current SVN) > Reporter: Jean-Baptiste Quenot > Attachments: 20051212-portal-MapProfileLS, 20051222-MapProfileLS.java, > 20051222-MapProfileLS.java, portal-config > > 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 > http://issues.apache.org/jira/browse/COCOON-1708 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: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
