Return-Path: 
 <dev-return-88633-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org>
Delivered-To: apmail-cocoon-dev-archive@www.apache.org
Received: (qmail 9953 invoked from network); 31 Jul 2006 12:15:55 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur.apache.org with SMTP; 31 Jul 2006 12:15:55 -0000
Received: (qmail 95232 invoked by uid 500); 31 Jul 2006 12:15:53 -0000
Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org
Received: (qmail 95166 invoked by uid 500); 31 Jul 2006 12:15:53 -0000
Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:dev-help@cocoon.apache.org>
list-unsubscribe: <mailto:dev-unsubscribe@cocoon.apache.org>
List-Post: <mailto:dev@cocoon.apache.org>
Reply-To: dev@cocoon.apache.org
List-Id: <dev.cocoon.apache.org>
Delivered-To: mailing list dev@cocoon.apache.org
Received: (qmail 95155 invoked by uid 99); 31 Jul 2006 12:15:53 -0000
Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 31 Jul 2006 05:15:53 -0700
X-ASF-Spam-Status: No, hits=0.0 required=10.0
	tests=
X-Spam-Check-By: apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Received: from [212.85.125.162] (HELO v07528.home.net.pl) (212.85.125.162)
    by apache.org (qpsmtpd/0.29) with SMTP; Mon, 31 Jul 2006 05:15:52 -0700
Received: from sj163.internetdsl.tpnet.pl (HELO ?192.168.1.62?)
 (lgawron.mobilebox@home@80.55.87.163)
  by m029.home.net.pl with SMTP; Mon, 31 Jul 2006 12:15:32 -0000
Message-ID: <44CDF46C.9070001@mobilebox.pl>
Date: Mon, 31 Jul 2006 14:15:40 +0200
From: Leszek Gawron <lgawron@mobilebox.pl>
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: Continuations consume ram, possible solutions?
References: <A955EA1F8FE31749AEC8C998082F6C7CBA909B@hai01.hippo.local>
 <98e4f1cd0607270712i77e3bc41j6db1bf9c5f4758a@mail.gmail.com>
In-Reply-To: <98e4f1cd0607270712i77e3bc41j6db1bf9c5f4758a@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked by ClamAV on apache.org
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N

Torsten Curdt wrote:
> <snip/>
> 
> IMO the only way to solve this transparently is to more accressively
> expire and limit the number of continuations. It would make sense to
> come up with a LRU list of continuations per session. This list has a
> maximum size that can defined. So the required maximum can is
> predictable. Generating more continuations means using free slots or
> throwing away the oldest ones in that LRU list. The janitor would
> basically only go through the list and expire to free the slots in
> that list.
Not that easy II: In almost every web application I choose the option to 
store continuations in session rather then in one place. This way all 
continuations get removed when the session expires.

You would have to traverse all sessions to decide which continuations 
you will remove.

BTW: users should be warned somewhere in docs that if they use session 
they better be using session bound continuations. Otherwise you run a 
continuation with session already invalidated and usually you get very 
funny (or dangerous) results like seeing some application data after 
logging out.

-- 
Leszek Gawron                                      lgawron@mobilebox.pl
IT Manager                                         MobileBox sp. z o.o.
+48 (61) 855 06 67                              http://www.mobilebox.pl
mobile: +48 (501) 720 812                       fax: +48 (61) 853 29 65