Marcus Crafter wrote: >>>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 ?) > Actually in your case, you do not need to implement any listeners. Simply obtain references to the ProfileSampleDescriptors you are interrested in and call getValue() or getSnapshot() each time you need a value.
The problem is that it is not really possible to build a truely pull based system which would be efficient. Especially across the network. Lets take the Counter example: For each event, the increment() method is called right? Someplace, you need to be keeping track of the number of times that increment() is called. You could create a class CounterSinceLastGetProfileProfilePoint or something but the flow of information is still push until the data gets to the ProfilePoint. Then at that point, the you can start to pull be making requests of getCount() to the ProfilePoint. I guess each call would reset the count etc. One problem here is that the rate at which getCount is called could actually be quite eratic especially if the calls are initiated across the network. A second problem is that it is not possible to have more than one client calling getValue() because each call resets the count. You will have similar problems with Max/Min/Average value ProfilePoints as well. Now take the ProfileSample case: The ProfileSample effectivly does the same thing as the CounterSinceLastGetProfileProfilePoint above except that there can be more than one of them. The data is push until the ProfileSample, but from that point it is entirely pull. The ProfileSample uses the timestamps provided with each event rather than calling System.currentTimeMillis(), so they are much more accurate. When a client does request data, it does not matter if they missed a few sample intervals because of some latency, the data, correctly intervalled, will all still be there. > 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 agree, this is one area which is more difficult. But what are some scenarios of what you would like to do? If you need to have hourly and per-minute reports, then you really need two sets of sample history, so the ProfileSamples would meet your needs nicely. If you need to really be dynamic. Then we would need to add a way to add and remove ProfileSamples at runtime. Remeber that by doing so the data would start when the ProfleSample was added. There is no way to create information out of thin air. So this does not seem to me useful unless the generation of a daily report is to take 24 hours to create. Setting up a ProfileSample would have the data there for you and the report would just get a snapshot when the report was scheduled to be generated. > 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) ? > Explain what you would like to do and I will see if I have any ideas. >>> 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. > See the mail in reply to Berin a few minutes ago. There is nothing stopping a Reporting tool from having its own configuration file. The >Optional< profiler configuration file is only used to setup system wide ProfileSamples and to define Descriptions for Profiler elements which will be made available through the Descriptor classes. It should be thought of as the place to define things which will be the same for all users of the system. :-) > 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. :-) > Thank you. I am glad to see all the interest in it. All of the feedback has really made me think about some areas that I had not thought of before. Getting it up and running with Cocoon as it is now would require adding Profiler support to the ECM. I talked about that in the mail to Berin. Should be neat though because much of Cocoon could be profiled without changing any Cocoon classes. Thanks, Leif
