Mailing-List: contact users-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@cocoon.apache.org
Received-SPF: pass (nike.apache.org: domain of NilsKaiser@gmx.net designates
 213.165.64.20 as permitted sender)
Message-ID: <4C0D5CBD.7020304@gmx.net>
Date: Mon, 07 Jun 2010 22:55:25 +0200
From: Nils Kaiser <NilsKaiser@gmx.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de;
 rv:1.9.2.5pre) Gecko/20100430 Lightning/1.0b2pre Thunderbird/3.1b2
MIME-Version: 1.0
To: users@cocoon.apache.org
Subject: high memory usage in MemoryAspectDataStore (portal block)
Content-Type: multipart/alternative;
 boundary="------------050504090806030308030903"

--------------050504090806030308030903
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

     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

--------------050504090806030308030903
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-15">
  </head>
  <body bgcolor="#ffffff" text="#000000">
    <meta http-equiv="Content-Type" content="text/html;
      charset=ISO-8859-15">
    <meta name="GENERATOR" content="BLOCKNOTE.NET">
    <title></title>
    <style>BODY { FONT-FAMILY:Tahoma; FONT-SIZE:10pt }
P { FONT-FAMILY:Tahoma; FONT-SIZE:10pt }
DIV { FONT-FAMILY:Tahoma; FONT-SIZE:10pt }
TD { FONT-FAMILY:Tahoma; FONT-SIZE:10pt }
</style><basefont face="Tahoma" size="2">Hi all,
    <div>�</div>
    <div>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).</div>
    <div>�</div>
    <div>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 "<font face="monospace">Use
        only the 'memory' aspect store with aspect datas!", so I did not
        try that.</font></div>
    <div>�</div>
    <div>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 (<font face="monospace">GroupBasedProfileManager.login()),
        which in turn writes the aspect data for every coplet to the
        MemoryAspectDataStore</font>, where it seem to stay forever.</div>
    <div>�</div>
    <div>Is this normal behavior or does it happen to an invalid
      configuration?</div>
    <div>�</div>
    <div>Thanks for any hint!</div>
    <div>�</div>
    <div>Best regards,</div>
    <div>�</div>
    <div>Nils Kaiser</div>
  </body>
</html>

--------------050504090806030308030903--