Hi,
I actually found out what was wrong! We had accidentally set the
pipelines for profile loading (pipeline "load-global-profile") to
"noncaching", which caused Cocoon (GroupBasedProfileManager) to reload
the profile at every login instead of once!
Maybe that should be mentioned in the documentation for the portal
profiles and in a comment in cocoon.xconf or the 2.2 spring files... Or
GroupBasedProfileManager could throw an exception as it is creating a
memory leak with the wrong behavior.
Best,
Nils Kaiser
Am 07.06.2010 22:55, schrieb Nils Kaiser:
Hi all,
I am having trouble with a cocoon 2.1 portal application. We use a
single layout for the site, users cannot really customize it but some
maximizing/restoring is done (a search coplet that maximizes to show
search results for example).
At the moment, the servers are restarted every night as memory usage
is increasing over the day. A heap dump analysis showed that the
MemoryAspectDataStore grows to ~300MB, with ~300000 entries in the
store (HashMap). These result from coplet data aspect for the aspects
"sizable" and "mandatory" being saved in the MemoryAspectDataStore. I
thought a quick solution would have been to change their store from
"memory" to "session", but there is a comment in the original
cocoon.xconf "Use only the 'memory' aspect store with aspect datas!",
so I did not try that.
I couldn't find any code that empties the store or deletes formerly
added entries, so I suppose that something is wrong with our usage of
layout / coplet data objects? Both coplet instance data and layout
data are currently saved and read to xml files on disk as some
information is stored in the user objects. Also, the application
automatically creates a user for any new session, which adds 15
entries to the MemoryAspectDataStore. It seems that the login
(LoginAction) of the user (anonymous or regular) triggers a loading of
the profile (GroupBasedProfileManager.login()), which in turn writes
the aspect data for every coplet to the MemoryAspectDataStore, where
it seem to stay forever.
Is this normal behavior or does it happen to an invalid configuration?
Thanks for any hint!
Best regards,
Nils Kaiser
