Hello Arno, Thanks for your attention once again! I have no idea why the THttpConnection ConnectionDataSent uses Shutdown(1) instead of Close(). We just inherited the code from there. I think this is something Francois can answer.
Best Regards, SZ ----- Original Message ----- From: "Arno Garrels" <[EMAIL PROTECTED]> To: "ICS support mailing" <twsocket@elists.org> Sent: Wednesday, March 14, 2007 5:22 PM Subject: Re: [twsocket] Bug in MT THttpConnection close logic > One question, why don't you call THttpMTConnection.Close? > TCustomWSocket.InternalClose calls ShutDown(1) and subsequently > close the socket handle as well as triggers SessionClosed > as needed. So far I had no problems with calling Close given > all data has been sent before (that is calling it from event > DataSent). > > -- > Arno Garrels [TeamICS] > http://www.overbyte.be/eng/overbyte/teamics.html > > > Fastream Technologies wrote: >> Hello, >> >> I have a modified THttpServer called THttpMTServer. In thic >> component, there are worker threads which are pooled and connection >> objects (THttpMTConnection) which are also pooled. I have the >> following code called >>> from ConnectionDataSent: >> >> void __fastcall httpServerClientClass::ConnectionDataSent(TObject >> *Sender, WORD Error) >> { >> if(!FDocStream) >> return; >> >> if(DataSent >= DataToBeSent || Error) >> { >> this->Error = Error; >> >> endOfResponse(); >> >> return; >> } >> >> ... >> >> Now in endOfResponse(): >> >> void __fastcall httpServerClientClass::endOfResponse(void) >> { >> if(CGIISAPIInAction) >> { >> scheduledToDestroy = true; >> return; >> } >> >> if(responseEnded) >> return; >> >> responseEnded = true; >> ... >> >> if(FSessionClosedFlag) >> { >> if(pendingHeaderAvailable && availableDataBufferLen <= 2) >> { >> pendingHeaderAvailable = false; >> availableDataBufferLen = 0; >> availableDataBuffer.SetLength(0); >> } >> } >> else if(!KeepAlive || Error) >> Shutdown(1); >> } >> >> Also in OnClientDisconnected: >> >> void __fastcall httpServerThread::HTTPServerClientDisconnected(TObject >> *Sender, TObject *Client, WORD Error) >> { >> httpServerClientClass *clientObject = (httpServerClientClass*)Client; >> >> ... >> >> clientObject->Error = Error; >> >> clientObject->endOfResponse(); >> clientObject->beginDetach(); >> } >> //-------------------------------------------------------------------- >> ------- >> >> and in beginDetach(): >> >> void __fastcall httpServerClientClass::beginDetach(void) >> { >> if(CGIISAPIInAction) >> { >> scheduledToDestroy = true; >> return; >> } >> >> if(!detachBegan) >> { >> detachBegan = true; >> >> while(!PostThreadMessage(affinityThread->ThreadID, >> WM_HTTP_CLIENT_THREAD_DETACH, (WPARAM)this, 0)) >> ::Sleep(1); >> } >> } >> //-------------------------------------------------------------------- >> ------- >> >> For some reason sometimes with slow/WAN connections, when clients are >> remote, this code does not work and the client object is "hung", >> eventually filling the maximum number of connections. I have a strong >> feeling that under some circumstances, the OnClientDisconnected is >> not being called. Or maybe there is something else wrong. (BTW, the >> flags such as detachBegan are correctly reset after each >> THREAD_ATTACH.) >> >> BR, >> >> Gorkem > -- > To unsubscribe or change your settings for TWSocket mailing list > please goto http://www.elists.org/mailman/listinfo/twsocket > Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
