I can see how code could make the problem worse, but in our case, we
could never fix it completely.
It took 2 months of tracing with primebase engineers to fix issues in
their odbc implementation. And once we worked them all out, witango
never went down. It never crashed, or hung, for months on end.
Then they release and update, it started doing it again, they fixed,
and perfect again.
We then moved to mysql 5, and odbc 3.5.1 from mysql, and it has never
crashed or hung. My witango servers DO NOT go down. We can crash the
test servers, trying out beans and stuff, but they just run.
I do think this issue, is not on the witango side, maybe witango
could find a way, to keep from crashing, when the odbc system does,
because it is MUCH better then it was in v5, but ultimately, at least
for us, work through the odbc issues, and witango 5.5.009 is rock
solid. And we are pushing millions of blobs through it a day, with a
dslife of only 10 mins.
--
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:22 AM, [EMAIL PROTECTED] wrote:
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
