Well, one of the major changes in 5.5, seemed to directly address this issue. Periodically, other witango shops have consulted with me, giving me access to their systems. This issue, was always related to the odbc system being used, or oracle, and to some degree fixable. For the most part, witango 5.5.009 is rock solid, and if you have to kill and restart more than once a month, you either have code issues, or some configuration, or db connectivity issue to fix.

My suggestion, would be to create a taf, and a mssql db that that you can then hammer in something like apache bench, with dslife at zero, and get it to do this, reliably over and over, and bundle it up, and send to witango inc, with instructions.

In my experience, this kind of thing, they will make a priority. However, they are probably going to tell you first to patch up your system, to latest 2003, so you have the latest sql client stuff.

When my odbc system was doing this, I could reproduce fairly easily with one taf, dslife of zero, and hammer it, and if you watch the processor performance, you will see that it happens frequently, where witango stops responding, but it recovers many times, but then, sometimes it doesn't.

--

Robert Garcia
President - BigHead Technology
VP Application Development - eventpix.com
13653 West Park Dr
Magalia, Ca 95954
ph: 530.645.4040 x222 fax: 530.645.4040
[EMAIL PROTECTED] - [EMAIL PROTECTED]
http://bighead.net/ - http://eventpix.com/

On May 26, 2006, at 7:29 AM, Christian Carrier wrote:

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

________________________________________________________________________
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf

Reply via email to