avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leif Mortenson <l...@tanukisoftware.com>
Subject Re: Instrument questions
Date Mon, 29 Apr 2002 17:19:04 GMT
Vincent Tence wrote:

>Looking at the javadoc of InstrumentSample, it suggests that we could
>add InstrumentSamples to an Instrument as a result of a request from an
>InstrumentClient. Does that mean we should add addInstrumentSample() and
>removeInstrumentSample() to InstrumentDescriptor interface?
I have been working out the issues with how to add samples at run time. 
 I am currently working on
a system where a client will request that a sample be added given a 
lease time.  The client must then
renew this lease or the sample will be destroyed by the 
InstrumentManager after the lease expires.

The benefits of this method are that the client does not have to worry 
about cleaning up its samples
in the event of an abnormal shutdown.

It also makes the case where multiple clients are using the same sample 
easier.  Each client requests
a lease and the InstrumentManager makes sure that the sample stays 
around until the later of the leases

Using leases also makes it possible for a client to request that a 
sample be registered to record data
event when the client is not connected.  The client could request a 
lease time of 24 hours before going
home at night.  Completely disconnect from the server.  Then reconnect 
the next morning and see the
results of the data that had been collected durring the night.

Currently this is about 75% impemented.  samples are created, but they 
do not yet expire.  You can try
it out using the instrument-client in CVS.

Samples are requested by a client using the createInstrumentSample() 
method of the InstrumentDescriptor.
The addInstrumentSample() method in the InstrumentProxy class should now 
be private.  Samples can
only be removed by the InstrumentManager when their lease expires, so a 
method is not needed.

Samples which are defined in the configuration file will never expire. 
 They are to be thought of as
resources that a client can always depend on.

Do you think I am going in the right direction here?

>>1. Clients access the Instrumentables through InstrumentableDescriptors
>>via the InstrumentClient. In the DefaultInstrumentManager, shouldn't we
>>reset the optimized arrays m_instrumentableProxyArray and
>>m_instrumentableDescriptorArray when a new InstrumentableProxy is added
>>in registerInstrumentable() (like we do in configure())? That way we
>>could add Instrumentables - not declared in the config - after configuration, 
>>which would be visible to clients
This was not intentional.  Good catch.  It should be fixed now in CVS. :-)

>>What was your idea behind registering Instrumentables not declared in the config?
>>I'm not sure to understand this correctly.
The InstrumentManager is actually designed to be completely independent. 
 You should be able
to register any Instrumentable at any time in the life of an 
application.  The Instrumentables defines
in the configuration are only necessary when things like names or static 
samples need to be declared.

>>2.To add new InstrumentSamples that have not been declared at configuration stage,

>>I would use the addXXXListeners() method on the InstrumentDescriptor in my client
>>and pass it an InstrumentSample. But those samples would only be visible to my client
>>- as opposed to those added via addInstrumentSample() - correct? 
>>(btw, is addInstrumentSample() in InstrumentProxy public on purpose?)
>>I may want to do that to let the administrator specify custom samples when the application
is running.
>>Is that possible?
See above.  Did I answer these questions.

I am currently reviewing the use of the listeners.  Especially making 
them available to remote clients.  The
problem is that the listener methods are fired in the thread where the 
data are taken.  If the listeners are
remote then this can severely affect the performance of the application.
Thoughts on this?

I was thinking about making a set of base descriptor interfaces which 
could be accessed remotely as
well as a set which are more for in JVM use by tools which would make 
the listener methods available.

For the samples, it is possible for the client to request snapshots or 
call any of the descriptor's methods
at their leasure without affecting the performance of the application. 
This can be done without listeners.

Keep the questions coming.

Also, any ideas for making the client more user friendly.  I was 
planning to add a tree like you had
made for the altprofile client.  The tree would be located in the window 
opened for each remote
InstrumentManager.  This was the user could get away from the menu 
driven interface.

I was also considering adding child instrumentables to the descriptors. 
 This way they would mirror
structure of the actual instrumentables.  Currently, the child 
instrumentables are only used for naming
the instruments which are all viewed as being direct instruments of the 
root instrumentable.   Not
only is this confusing, but I have found that it can cause problems in 
large applications as the total
number of instruments can grow quite large.
This can be done without changing the instrument project in any way. so 
no user code should be
affected.  The instrument.xml files would require some slight 
modifications though.

Finally, I am also planning to put the ability to save Instrument Sample 
snapshots to a state file
back in.  This was being done in the altprofile code.  I have been 
waiting until things settle down
a bit though.  The ability to save and load the desktop of the client 
will also be put back in.


To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

View raw message