Jean-Francois, I would agree that a fancy statistics collecting service would be VERY cool! In fact, if you want any help, let me know. It would be nice for a monitoring application to identify "hotspots" in the application which might need to be addressed. Now you've got me thinking! But, for simple debugging purposes, it might be overkill. I think we can do something like...
// Do begin logging final long before = System.currentTimeMillis(); // Call method. final long duration = System.currentTimeMillis() - before; // Do end logging printing out the duration. This would eliminate the effects of the logging on the actual duration calculation. I don't see how this could really cause a problem and I think it would be a nice feature. I agree that we're not separating concerns really, but I've done this in the past (separated it) and it's kind of annoying to have multiple logging messages when one could have sufficed. Also, you have to add two interceptors to each service as opposed to one (easier to do with Groovy descriptors). James -----Original Message----- From: Jean-Francois Poilpret [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 01, 2005 9:40 AM To: [email protected] Subject: RE: Timing interceptor? Except if we consider the benefits of separating concerns. The question is: is logging concern equivalent to performance measurement concern? Personally, I really prefer to have 2 different interceptors for this. In particular, I would probably want to check performance _without_ logging enabled (since logging would degrade the real performance). I already thought about writing such an interceptor, but I am not sure it is as easy as it sounds: I don't think it would be a good idea to just store somewhere the duration of ONE call to a method. It is generally better to have some kind of "statistics" (like: number of calls, average duration, min and max duration), and for this you need some additional configuration for your interceptor (in addition to where you want the information logged). Or maybe a better solution would be to have a simple interceptor that calls a "statistics" service at the end of each method call, passing it the method signature, the service-point, and the exec duration. Then it is up to the statistics service to do whatever it wants with that, from the simplest to the most complex. We could then provide "minimal" implementations for such a service. Cheers Jean-Francois -----Original Message----- From: James Carman [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 01, 2005 8:13 PM To: [email protected] Subject: RE: Timing interceptor? It still couldn't hurt to add this to the logging interceptor. -----Original Message----- From: Achim Huegen [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 01, 2005 8:10 AM To: [email protected] Subject: Re: Timing interceptor? I've included a performance interceptor in my hivemind jmx code. It measures duration of service calls and provides the results (min, max, avg etc.) via jmx. The code will be available during the next days as jira patch. Achim Huegen David J. M. Karlsen wrote: > Would it be interesting to create an interceptor that gives timing > information? (Time to enter and leave a method). > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
