Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 20336 invoked from network); 27 Jul 2006 14:39:15 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 27 Jul 2006 14:39:15 -0000 Received: (qmail 81494 invoked by uid 500); 27 Jul 2006 14:39:14 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 80965 invoked by uid 500); 27 Jul 2006 14:39:12 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@cocoon.apache.org List-Id: Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 80951 invoked by uid 99); 27 Jul 2006 14:39:12 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 27 Jul 2006 07:39:12 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: neutral (asf.osuosl.org: local policy) Received: from [68.230.240.36] (HELO eastrmmtao03.cox.net) (68.230.240.36) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 27 Jul 2006 07:39:12 -0700 Received: from [192.168.0.104] (really [70.179.64.83]) by eastrmmtao03.cox.net (InterMail vM.6.01.06.01 201-2131-130-101-20060113) with ESMTP id <20060727143850.YLYJ23863.eastrmmtao03.cox.net@[192.168.0.104]> for ; Thu, 27 Jul 2006 10:38:50 -0400 Message-ID: <44C8CFF3.3040401@reverycodes.com> Date: Thu, 27 Jul 2006 10:38:43 -0400 From: Vadim Gritsenko User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060530) MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Re: Continuations consume ram, possible solutions? References: <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: > > 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. +1 Vadim