Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (athena.apache.org: domain of dariusz.luksza@gmail.com
 designates 209.85.219.217 as permitted sender)
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=eVvDW6KL7iYsyPoCmxGKu9cm9eOyAm6oRF2nCPgSCOheg2W7uqsU/KdFYEFJky/93A
         VOYERBXQPbihkojIU78qeH6P6N20sr+5V31Morwn09K9HLtFTNd1lzCM/OmC/9zUw4WJ
         ddkhfuaPolh2a2Gl3rgisw9k6hWTqFJvL4NFA=
MIME-Version: 1.0
In-Reply-To: <a224cb0f0907241259j3575c0ebwcf8f854e8ceeccd2@mail.gmail.com>
References: <a224cb0f0907091116x7063ewa28d27ac73c8651e@mail.gmail.com>
	<a224cb0f0907120552w6f592c93y81671a15d89d7376@mail.gmail.com>
	<4A5E236C.5090909@apache.org> <4A65A089.8040700@apache.org>
	<a224cb0f0907211053g2a015fb8r76f31b8cccc97fc5@mail.gmail.com>
	<a224cb0f0907241259j3575c0ebwcf8f854e8ceeccd2@mail.gmail.com>
From: =?UTF-8?Q?Dariusz_=C5=81uksza?= <dariusz.luksza@gmail.com>
Date: Fri, 24 Jul 2009 22:29:39 +0200
Message-ID: <a224cb0f0907241329o3fd8d980oa52a82480957d080@mail.gmail.com>
Subject: Re: [c3 monitoring] Cache overview
To: dev@cocoon.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

2009/7/24 Dariusz =C5=81uksza <dariusz.luksza@gmail.com>:
> 2009/7/21 Dariusz =C5=81uksza <dariusz.luksza@gmail.com>:
>> On Tue, Jul 21, 2009 at 1:03 PM, Reinhard P=C3=B6tz<reinhard@apache.org>=
 wrote:
>>> Simone Gianni wrote:
>>>> Hi Dariusz,
>>>> I had a look at your patch. I see the method "listKeys", with the
>>>> description "Removes all cached data". I think this is an error, looki=
ng
>>>> at the source it lists cache key names, and does not remove them, whil=
e
>>>> the "clear" method does that.
>>>>
>>>> Apart from this small error, regarding your question, I'm trying to
>>>> figure out what a user will want to see when checking the cache.
>>>>
>>>> I'm brainstorming here, trying to paint a big picture, probably the re=
al
>>>> features will be much smaller, but this could provide you ideas and at
>>>> the same time help identify which ones are most important.
>>>>
>>>> I can think of three possible scenarios :
>>>> - While developing, they see something they don't expect to see, and
>>>> they go check if there is some cached data in the way.
>>>> - While optimizing the application, they go check what happens in the
>>>> cache, if/how they are wasting RAM by caching too much or wasting CPU =
by
>>>> not caching enough.
>>>> - At runtime, they could access it to see what's going wrong, to recov=
er
>>>> some ram, to clear everything if they just published something really
>>>> important and they want it to appear now.
>>>>
>>>> Given these three scenarios, these are things that may be useful to se=
e
>>>> 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
>>>> for ComponentCacheKey)
>>>> - Which "pipeline" I'm referring to, so that if it's not working
>>>> properly I can check if there is cached stuff.
>>>
>>> In Cocoon 2.x, a pipeline can have and ID attribute. For the purpose of
>>> drilling down caching entries we could introduce it in 3.0 too. (I've
>>> always wondered about the use case for pipeline ids ...)
>>>
>>
>> Thanks for that tip I'll look on this ASAP ;)
>>
>
> For our needs every pipeline should have an id parameter, from one
> hand it is very good solution because we get simple way how to divide
> and present cache entry's on JMX and on the other hand I'm not quite
> sure that we can require that parameter for every pipeline and user even =
if he
> don't use monitoring module
>
> What do you think ?
>

There is also third solution ... pipeline id parameter can be optional
and we'll publish on JMX _only_ that cache entry's that belongs to
pipeline that have set id parameter. This approach gives us additional
configuration options and can reduce amount of data published on JMX.
IMHO this is the best solution right now.

--=20
Best regards

Blog: http://luksza.org
LinkedIn: http://www.linkedin.com/in/dariuszluksza