tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Remy Maucherat" <>
Subject Re: [TC4] ResourcesBase.setCheckInterval() bug and HTTP
Date Fri, 17 Nov 2000 02:29:25 GMT
> Remy Maucherat wrote:
> > > You're correct that this kind of code is appropriate (because the
> > component
> > > has already been started without the thread).
> >
> > Really ? The threadStart() call is in the start() method, and
> > is always called in stop(). How would the thread need to be started if
> > component is not started yet ?
> >
> Consider that you might initialize a resources object with this (among
> stuff):
>     resources.setCheckInterval(0);
>     resources.start();
> and later on, while the container is running, an admin application
> this:
>     resources.setCheckInterval(15);
> The thread wasn't started inside resources.start() because the check
> was zero at that time.  Therefore, it *does* need to be started if
> setCheckInterval() is called later.

 if (started) {
     if ((oldCheckInterval > 0) && (this.checkInterval <= 0))
     else if ((oldCheckInterval <= 0) && (this.checkInterval > 0))

I think it is.
In your case, the first setCheckInterval(0) won't start the thread, as
started = false.
The started flag is switched to true by start().
The setCheckInterval(15) will start the thread correctly, since (started) is
true, and ((oldCheckInterval <= 0) && (this.checkInterval > 0)) is true too
(the old value was too low, the new one is right).

> For long-running servers, we need to remember that configuration is not a
> one-time event.  (By the way, IMHO, this is one of the few places where
> doesn't quite "get it".)

There was a reconfigurable interface at some point. I don't know if it's
still there.

The new HTTP stuff looks like it's working. I tested with all my servlets
suite (including Slide), and I was using ridiculously small buffers (between
1 and 4 bytes) while testing.
HttpProcessor is still very similar to what it was before (but not for
long). Basically, what I did is I wrote a set of buffer classes (which I can
recycle), and I wraped the socket input stream using a tweaked
BufferedInputStream. This input stream directly manipulates the internal
buffer and the position pointer to achieve maximum performance. I don't
think that part can be optimized more, since whatever happens, I'm only
reading a character (from the internal buffer) once for every operation
(reading the request line or reading the headers).
What is coming next is that the HttpProcessor and the Request object will
only use those recyclable objects (instead of Strings). Hopefully, the only
things which will have to be garbage collected is the Strings generated for
many of the servlet API function calls. That should bring another very nice
increase in performance :)
After that, I'll optimize the output, as Costin suggested.


View raw message