Hi Leif,
On Thu, Mar 07, 2002 at 09:52:28PM +0900, Leif Mortenson wrote:
>
> > I've tried to get my head around your design, etc. Please tell
> > me if the following analysis is right:
> >
> > -----------------------------------------------------------------
> >
> > The profile manager maintains a list of profilable objects,
> > registered either automatically by the profilable component
> > manager, or manually via a registerProfilable() method on the
> > manager itself.
>
>
> Correct.
This is nice, it allows one to implement a ProfilableComponentManager
as you did, but also to register non-component objects too, which is
great for profiling legacy not-yet-avalon-based code. Cool :-)
> > Each profilable exposes 0 to many profile points which maybe of
> > type 'value', or 'counter'.
> >
> > Upon registration with the profile manager, a profilable proxy
> > is created which manages profile point proxies across threadsafe
> > and non thread safe components.
>
> Correct.
Nice work with the proxies - I hadn't yet considered the
threadsafe/non-threadsafe issue.
> > Profile point proxies let you register listener classes for
> > updates from the profile points themselves. The listeners can be
> > implementors of a lower level ProfilePointListener class, or
> > high level Sample classes.
>
> Almost. The ProfilePointListener is not meant to be implemented directly.
> It is just the super class of the CounterProfilePointListener and
> ValueProfilePointListener interfaces. Those two types of listeners can be
> regestered with a ProfilePoint through the addCounterProfilePointListener
> and addValueProfilePointListener methods of a ProfilePointDescriptor object.
>
> The Samples are at a higher level and have their own ProfileSampleListener
> interface for listeners which register with them.
Ok. I'm wondering why the choice of a observer-observee model inside
the profiler manager, instead of a pull method from the reporting
class ?
Perhaps, let me explain what I was hoping to do with the profiler.
We have a Cocoon application that runs over 4 load balanced
machines in production. I'm currently in the process of putting
together an architecture for building an administration
application for our production folk that can (among other
things) offer profiling information about actions performed in
production (the normal stuff, number of reports generated/hour, number
of login's/hour, memory usage, etc).
What I wanted to for them was create an admin application, that
would run on a separate machine somewhere, but obtain profiling data
from the production machines via some network procotol (eg. perhaps
SOAP the latest profiling data into a cocon pipeline and format it as
html or an svg chart, or into a swing based gui tool).
The data displayed could then also be updated on-demand via a
simple 'reload'.
For our management however, I was also hoping to create a text
based reporter that would, at the end of the day facilitate them
with the latest daily data (total number login's, total reports
generated, etc).
The 2 reports contain different data, but are using the same profile
points.
Using a pull model, the different reporting implementations
could access the profilables directly and get/save the data when
it's required.
With a listener based approach you'd need to write a listener
class that is updated with profile point data, but accessed by the
reporting class when on-demand data is required. This incurs an extra
step as the listener implementation is essentially acting as a
pullable source for the data (or have I misunderstood something ?)
The other thing is I would like to be able to change the sample
rates dynamically on particular profilables. With the reporting
tool pulling the data down (basically acting as the driver), this is
easy and can be made a part of the gui tool. I'm not sure how it could
be easily done with the listener approach ?
I think we can achive the same observer-observee idea with a
pull model, it just involves moving some of the driving code
into the reporting engine (at some abstract level) ?
> > The profile manager can be configured to automatically create a
> > set of listeners (samplers in this case) for particular profile
> > points
> > on a particular profilable. Samplers configured in this way can
> > be accessed via the profile manager. The gui reporter essentially
> > iterates through the list of available samplers when building
> > it's menu's.
>
>
> Correct.
This is really nice, the format of the config file is good and
makes things quite easy to configure.
I'd find it nicer though if this configuration file configured the gui
tool (or some other reporting implementation) instead of the profiler
itself. Then we could facilitate the use of multiple simultaneous
reporting engines, each with different configurations.
What are your thoughts about all the above ?
Awesome stuff though mate! I'm really looking forward to getting
this up and running in our application and in cocoon itself. :-)
Cheers,
Marcus
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: ManageSoft GmbH
$ o_)$$$: 82-84 Mainzer Landstrasse
;$, _/\ &&:' 60327 Frankfurt Germany
' /( &&&
\_&&&&'
&&&&.
&&&&&&&:
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
