----------------------------------------------------------------
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 have no clue what's causing the
> errors exactly, but I'm guessing that the errors you're getting with
> Solaris are a result of having to initialize a new socket for each request
> in turn, resulting in a more obvious manifestation of any "boundary
> conition" problems inherent in the patch. Then once sockets are present in
> the unshared per-process scoreboards, there are no errors. The problem may
> be present under NT, but you would notice it at most once, since after the
> first request has been answered, the socket scoreboard has a socket
> available for all subsequent requests. I think this analysis is consistent
> with the fact that you find errors intermittently towards the beginning of
> your test, but not towards the end of your test (under Solaris).
This was my first guess, but I don't think this is what's happening. The
socket scoreboard is indexed by the request -> child_num value. While
the idea of a scoreboard is superfluous in multi-process Unix, I
observed that each process would in fact have the same request ->
child_num value, and would therefore access the same scoreboard slot for
every request. If a new socket for each request is initiliazed, then,
because the first request does work, I would expect no errors until the
scoreboard is filled, and not the
succeed/fail/succeed/fail/succeed/fail... succeed scenario. The
consistent 'request after' failure indicated to me that the socket was
being re-used.
In fact, as I attempted to work through the problem, I put in a debug
statement to verify the actual socket. In the observed failures, it was
the same socket. One thing to question is my assumption about the
request -> child_num values being generated. Should they really be used
to index a socket scoreboard?
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]
