Remy Maucherat wrote:
> > 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
> threadStop()
> > > is always called in stop(). How would the thread need to be started if
> the
> > > component is not started yet ?
> > >
> >
> > Consider that you might initialize a resources object with this (among
> other
> > stuff):
> >
> > resources.setCheckInterval(0);
> > resources.start();
> >
> > and later on, while the container is running, an admin application
> executes
> > this:
> >
> > resources.setCheckInterval(15);
> >
> > The thread wasn't started inside resources.start() because the check
> interval
> > 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))
> threadStop();
> else if ((oldCheckInterval <= 0) && (this.checkInterval > 0))
> threadStart();
> }
>
> 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().
*BUT* the start() method does not start the background thread if check interval
was zero at that time. Check the last couple lines of the start() method:
if (checkInterval > 0)
threadStart();
Thus, the thread was not started in the scenario I quoted, even though "started"
is true.
>
> 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
> Avalon
> > 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.
>
Sounds good.
>
> Remy
Craig
