Manuel Segarra found the answer to the socket closing after 4 minutes problem on Windows. The adapter needs to not call shutdown() on the socket after sending all of the data.
I manually removed the call from my copy of Webware, and it seems to work, except that now XML-RPC requests never return at all. I suspect that the XML-RPC code in WebKit is relying on the socket being shutdown to detect the end of data, instead of reading the content-length env var to determine the length of data. That will have to be fixed. Do any of the socket experts out there see any problem with removing the call to shutdown? (Or at least moving it so that shutdown() isn't called until _after_ the response is received from the appserver?) - Geoff -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Monday, April 15, 2002 2:59 AM To: Geoffrey Talvola Subject: RE: [Webware-discuss] Connection reset by peer when long running request Hello again, After some tests I realized that the sentence s.shutdown(1) in transactWithAppServer(Adapter.py) is leaving the socked (on Windows) in a TIME_WAIT state. When a socket is in TIME_WAIT state windows will release its resources after a time controlled by TcpTimedWaitDelay registry entry, it defaults to 240 s (4 min). This parameter should NOT be changed in order to obtain more time to process request, moreover, everywhere advises to reduce to 30s in order to improve server connections/second. I comment the line which results not changing the ESTABLISHED status of the socket. And then request can run forever (almost) ;-) So nothing to do with KeepAlive etc, as suggested by the thread you indicated, keepalive traffic triggers after 2 hours of inactivity by default !!! (I will not post this answer to the list since I am not subscribed and I don�t know how to do it after when responding). Thanks. _______________________________________________ Webware-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss
