Re: [TC4] ResourcesBase.setCheckInterval() bug and HTTP

[Remy Maucherat <re...@apache.org>]

> 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().
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.

Remy

Re: [TC4] ResourcesBase.setCheckInterval() bug and HTTP

["Craig R. McClanahan" <Cr...@eng.sun.com>]

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