From dev-return-101670-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org Fri Jul 17 12:32:06 2009 Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 8907 invoked from network); 17 Jul 2009 12:32:06 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 17 Jul 2009 12:32:06 -0000 Received: (qmail 18078 invoked by uid 500); 17 Jul 2009 12:33:11 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 17972 invoked by uid 500); 17 Jul 2009 12:33:11 -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 17964 invoked by uid 99); 17 Jul 2009 12:33:11 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 17 Jul 2009 12:33:11 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of dariusz.luksza@gmail.com designates 209.85.212.194 as permitted sender) Received: from [209.85.212.194] (HELO mail-vw0-f194.google.com) (209.85.212.194) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 17 Jul 2009 12:33:00 +0000 Received: by vwj32 with SMTP id 32so696176vwj.18 for ; Fri, 17 Jul 2009 05:32:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:content-type :content-transfer-encoding; bh=3yYT5/ryFD4xLFF4ml09rLeBUQSKIDCa6Y1SdYaPFe8=; b=Dkc5PQls7Jn+EamqDbEz38tfEcAqV+yxQS70KnlKhmxkDfk825pVEyXX0Yb8d9maWx bVnzYSRWke/j2bbT6JikVNkeK5CQ038A6STUrtWdXpDeO2/eqyp20J3XXVrdRM00jHH3 iHKpWZf0GjFelgqMWK8iGwIU0q+dWhS/vt7+U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; b=cWzOPjWhHDZSF1B8vnTD1vhheGCUcKpi5iZkD3cbeGuaaRHFbPbw+wLljJ4yrtNQuu UyNgIOCzb+bcZrY5wvZvgOvj7/kW4/upWQJWsZ1D8vpVuBxcoeIDq8lOHx9Z59X3pipm GTGWbSYFTPdaneiN/95rKcOSOkVgO6x6YceFs= MIME-Version: 1.0 Received: by 10.220.81.69 with SMTP id w5mr1501736vck.23.1247833959169; Fri, 17 Jul 2009 05:32:39 -0700 (PDT) In-Reply-To: <4A60091B.2000002@apache.org> References: <4A5E236C.5090909@apache.org> <4A60091B.2000002@apache.org> From: =?UTF-8?Q?Dariusz_=C5=81uksza?= Date: Fri, 17 Jul 2009 14:32:19 +0200 Message-ID: Subject: Re: [c3 monitoring] Cache overview To: dev@cocoon.apache.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org On Fri, Jul 17, 2009 at 7:16 AM, Reinhard P=C3=B6tz wr= ote: > Dariusz =C5=81uksza wrote: >> On Wed, Jul 15, 2009 at 8:43 PM, Simone Gianni wrote= : >>> >>> Given these three scenarios, these are things that may be useful to see= via >>> JMX, but I don't know which of them are actually achievable or already >>> there, so this is an "abstract" POV : >>> - The component that stored that entry (it's part of the name already f= or >>> ComponentCacheKey) >>> - Which "pipeline" I'm referring to, so that if it's not working proper= ly I >>> can check if there is cached stuff. >>> - The size of the entry, I see it is possible to obtain it from CacheKe= y >>> with your patch. this is useful if I'm profiling or in desperate need t= o >>> free some ram. >>> - When that entry will expire by itself, if it will. >>> - Last time that entry has been used (red) from the cache, if ever. >> >> Here you generally refer to single cache entry. But question how to >> represent cache entry on JMX tree is still actual. I have two ideas >> how we can do that: >> - based on URL with they published >> - based on pipeline and type of cache > > Just one quick comment for now (I'll get back to you with more thoughts > at the weekend but the discussions already goes into the right direction > IMHO): > Does this still work if you have thousands or tens of thousands cache > entries? > In this case it'll cost some CPU time and user patience to find elemnt that he is actually looking for, but right now I don't have anny other ideas ... --=20 Best regards Blog: http://luksza.org LinkedIn: http://www.linkedin.com/in/dariuszluksza