Thanks for the detailed answers. See answers inline
-- Vincent > -----Original Message----- > From: Leif Mortenson [mailto:[EMAIL PROTECTED]] > Sent: Monday, April 29, 2002 1:19 PM > To: Avalon Developers List > Subject: Re: Instrument questions > > > 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 > expires. > > 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 > removeInstrumentSample > 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? Sure. I like your idea of the lease time. I was thinking yesterday that clients should be able to add samples at run time, but then I did not want the manager to expose too much to the clients for its own integrity. The lease time looks like a good compromise. > > >>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. :-) Cool. > > >>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. I'm glad to hear that. That's what I thought seeing all the nice synchronization code you put in. > > >>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 code > >>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. Nicely. It all makes sense. > > 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. Is it possible that the descriptors accessed by remote clients spawn threads in which they notify listeners? That's just a thought, since I rarely do remote stuff. I have to take a look at altrmi to see how this works. > > 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. That would be nice indeed. > > 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. Could you explain a little be further what you have in mind? > > Cheers, > Leif > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
