I have a similar solution that essentially polls the webserver looking at response codes and kills the process when it is hung. The service then intelligently figures out the pid and kills the correct Witango.exe based on process id and restarts the service. I just find it disheartening that we have a very large site (100,000's of page request per day) on 5.5.006 and Windows 2003 that does not exhibit this behavior. Since we have gone to service pack one the problem seems to happen very often. Has Witango ever confirmed or denied that they can reproduce this issue?
-Christian -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, May 26, 2006 10:23 AM To: [email protected] Subject: Re: Witango-Talk: 605 Errors Causing Unresponsive Witango 5.5 Server on Windows 2003 SP1 Hi, Christian. This ODBC Spawn Issue has been discussed before, and as I and my colleagues believe it is originated by ineffecient code, rather than anything else. ODBC Driver is just a middle tier, that fails to sustain certain conditions. Although if you want to have a hack solution to deal with this problem. You might want to switch Witango Service Account from Local System to some other Domain Account, then you'd be able to use RPC Calls to kill and restart an instance if it hung. We have been dealing with ODBC SPAWN issues by automating Restart procedures using Rkill utility from Windows Resource Kit. Sincerely, Andre Rekhtine, Sr. IS Consultant, MCSE Moveable Online Inc. > Sorry I accidently sent that first post without finishing it. Since we > have > been deploying Witango 5.5 (Professional usually running 4 instances of > the > service) with Windows 2003 Server SP1 we have been experience intermittent > 605 errors. We are running a web based application connected to a SQL > Server > 2000 backend. I know that 605 means that the ISAPI client could not > connect > to the application server (In fact Phil may remember that they created > these > codes for us when we first started testing Witango 5.5 for a fairly large > customer that needed to support a lot of concurrency). I have attempted to > log the server but the logs get way to big (500mb's) to allow logging for > a > long period of time. The only error that appears is that the connection to > the database failed such as: > > 08/04/2006 07:43:32 10.2.9.63 [EMAIL PROTECTED] > 2920 > 1 33 [Datasource] No existing connection to > the > data source found, creating a new connection. DSN: XXX; User: XXX > > 08/04/2006 07:43:32 10.2.9.63 [EMAIL PROTECTED] > 2920 > 1 33 [Error] -109 This type of data source is > not supported by the server license. > > 08/04/2006 07:43:32 10.2.9.63 [EMAIL PROTECTED] > 2920 > 1 34 [Datasource] Unable to open to XXX due > to > an error during connection > > 08/04/2006 07:43:32 10.2.9.63 [EMAIL PROTECTED] > 2920 > 1 34 [Datasource] Total Connection in > Datasource Pool: 1 Max connections for the host: 0 Current connections in > use for the host: 0 > > 08/04/2006 07:43:32 10.2.9.63 [EMAIL PROTECTED] > 2920 > 1 34 [Error] -4 Unable to connect to the > specified data source. Verify that data source is properly configured and > that database server is online. > > > > However, This does not seem to correlate to a 605 error. Some of you may > or > may not know that the Witango ISAPI client communicates to the service via > TCP/IP sockets. It seems that there are occasions where either the ISAPI > or > the service does not properly close the socket connection. This causes the > server to orphan sockets in the CLOSE_WAIT state. When this occurs you > will > see page requests hang on request to the server then timeout with a 605 > (client IO timeout). Here is a sample of a netstat run at one of our > sites: > > > > TCP intrigue:18155 intrigue:3484 CLOSE_WAIT > > TCP intrigue:18156 intrigue:3698 CLOSE_WAIT > > TCP intrigue:18156 intrigue:3699 CLOSE_WAIT > > TCP intrigue:18156 intrigue:3921 CLOSE_WAIT > > TCP intrigue:18156 intrigue:4010 CLOSE_WAIT > > TCP intrigue:18156 intrigue:4011 CLOSE_WAIT > > TCP intrigue:18157 intrigue:1560 CLOSE_WAIT > > TCP intrigue:18157 intrigue:2184 CLOSE_WAIT > > TCP intrigue:18157 intrigue:3196 CLOSE_WAIT > > TCP intrigue:18157 intrigue:3423 CLOSE_WAIT > > TCP intrigue:18158 intrigue:2340 CLOSE_WAIT > > TCP intrigue:18158 intrigue:2536 CLOSE_WAIT > > TCP intrigue:18158 intrigue:3045 CLOSE_WAIT > > TCP intrigue:18158 intrigue:3209 CLOSE_WAIT > > > > You can notice that the problem spreads across all four instances of the > Witango Server. This causes the server to eventually become unresponsive. > Even when the server has on connection orphaned in the CLOSE_WAIT state, > the > service cannot be stopped and the Witango.exe process must be forcibly > killed. The only workaround I have found so far is to rewrite some of our > more commonly called pages in a different language (not a good solution). > If > anyone has made any progress on this I could use some help. The following > platforms seem to be stable with the same application running on them: > > > > Windows 2000 / SQL Server 2000 > > Windows 2003 (NOT SP1) / SQL Server 2000. > > > > Christian > > > ________________________________________________________________________ > TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf ________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf ________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
