cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcus Crafter <craft...@osa.de>
Subject Re: Cleaning up the CVS
Date Wed, 12 Dec 2001 00:07:11 GMT
Hi Stefano,

	Well, I should step forward and take some of the heat here.

Stefano Mazzocchi wrote:
> 6) the code contains a number of things that I found.... well.... let's
> me look for a polite way of saying this.... hmmm, ehmmmm, errrr, .....
>
>             if (this.getLogger().isDebugEnabled()) {
>                 incRequestCount();
>                 if (this.getLogger().isDebugEnabled()) {
>                     this.debug(environment, null, null);
>                 }
>             }

	I am partially responsible for this. The code below and part of the
	above came from a patch which I contributed

	(http://cvs.apache.org/viewcvs.cgi/xml-cocoon2/src/org/apache/cocoon/Cocoon.java.diff?r1=1.24&r2=1.25&diff_format=h)

> 7) still looking into Cocoon.java:748
>
>     /**
>      * Increment active request count for incoming requests, and save
> this
>      * result if it's the maximum.
>      */
>     private static synchronized void incRequestCount() {
>         if (++activeRequestCount > maxRequestCount) {
>             maxRequestCount = activeRequestCount;
>         }
>     }
>
>     /**
>      * Decrement active request count.
>      */
>     private static synchronized void decRequestCount() {
>         --activeRequestCount;
>     }
>
> what are these for? are you aware of the fact that adding a synchronized
> methods to the front door might create a *huge* bottleneck on high
> load!?!?!

	Yes, I am aware that this adds an extra overhead - the above methods
	should only be called if the application is logging debug statements.

	Ironically, I actually added these methods to our version of Cocoon to
	monitor what was happening while testing Cocoon under load, and also
	during a day's work in production.

	The idea was simply to log accurately, per request, the total number of
	requests being served at that time, and the maximum number of
	requests served for the applications life period.

	Being able to gauge such internal cocoon usage using this code has
	been invaluable for us, and has also helped us to fix 2 dynamic
	compilation problems in Cocoon (wrt sitemap & xsp code) and a session
	management problem wrt our application.

	My apologies if the code is not efficient, and I won't defend it
	if you think it's wrong. I'm quite keen to learn of a better way to
	ascertain this information and I'm open if you have any suggestions
	about how to improve it ?

	Cheers,

	Marcus

-- 
        .....
     ,,$$$$$$$$$,      Marcus Crafter
    ;$'      '$$$$:    Computer Systems Engineer
    $:         $$$$:   Open Software Associates GmbH
     $       o_)$$$:   82-84 Mainzer Landstrasse
     ;$,    _/\ &&:'   60327 Frankfurt Germany
       '     /( &&&
           \_&&&&'     Email : Marcus.Crafter@osa.de
          &&&&.        Business Hours : +49 69 9757 200
    &&&&&&&:


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message