----------------------------------------------------------------
BEFORE YOU POST, search the faq at <http://java.apache.org/faq/>
WHEN YOU POST, include all relevant version numbers, log files,
and configuration files. Don't make us guess your problem!!!
----------------------------------------------------------------
John Milan wrote:
>
> ----------------------------------------------------------------
> BEFORE YOU POST, search the faq at <http://java.apache.org/faq/>
> WHEN YOU POST, include all relevant version numbers, log files,
> and configuration files. Don't make us guess your problem!!!
> ----------------------------------------------------------------
>
> >
> > John is right : there is an extra overhead opening & closing a TCP
> > socket for each hit.
> > Costin did work on this, so did I, something could happen soon (maybe
> > experimental only, never released ?).
> > Anyway, even a single line of code will be granted.
> >
> > I disagree with the httpd.h hack need btw.
> >
> > Jean-Luc
> >
>
> It seemed necessary to perform proper handling of a timeout condition.
> Specifically, any persistent socket under timeout duress needs to be
> closed. If not, then JServ is still working under the assumption that it
> should complete the request and, given no runtime errors, *will* respond
> with data. And herein lay the problem, for if the timeout occurred,
> socket processing in the apache module stops, but the socket buffer may
> fill with data, and on a subsequent request utilizing the same socket,
> it will get the previous response from JServ. Do you have an
> alternative?
>
I wanted to make an additional point on this that is somewhat subtle,
but important. That is, currently apache controls such as timeout have
no effect on counterpart threads executing in the JServ Java VM process
space. Thus, a possible scenario today is a spike in requests to some
intensive resource, like a JDBC database, a 'freeze out' can occur. That
is to say, even though Apache may have correctly executed its timeout
operation, JServ is in fact still trying to serve all the requests. In
my opinion, this is a scalability problem.
The thing I like about inserting a callback handler for timeouts is
Apache can more or less immediately halt operation in the JServ VM since
any subsequent read or write to the underlying socket will fail and the
thread will die. We could take it a step further, so that we actually
communicate a kill request, but I'm not sure how much more effective it
would be. In general though, communicating an Apache timeout condition
in some way, shape or form strikes me as much more scalable.
Cheers,
John Milan
--
--------------------------------------------------------------
Please read the FAQ! <http://java.apache.org/faq/>
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/main/mail.html>
Problems?: [EMAIL PROTECTED]
