Marcus Crafter wrote:
>
> 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
ok, thanks for stepping up.
> > 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.
ok
> 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.
well, it's the quantum observer problem: looking at a system might
destroy the information that it previously contained. I mean:
introducing a potential bottleneck to test load might give you more
problems that it solved.
> 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.
see below
> 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.
cool, I'm happy it was useful, but I question the general usefulness of
such a thing.
> My apologies if the code is not efficient, and I won't defend it
> if you think it's wrong.
Well, the above code is clearly redundant and please let's avoid these
things in the future (not only for you, Marcus, I mean for everybody).
> 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 ?
The code seems to be collecting the maximum number of incoming
concurrent requests. It might be useful, I don't know, but for sure it
doesn't require synchronization. I mean: adding and subtracting one to a
counter is an atomic operation (on ints, it's not on longs, but we don't
have that many requests anyway).
The non-atomic operation is the comparison with previous maximum. One
possible simple solution is to have a sampling thread that reads that
value and logs it someplace. It might be useful for profiling
information.
What do you think?
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
