Bug #35184 Catastrophic failure at Connection (ASP vs MySQL)
Submitted: 10 Mar 2008 15:16 Modified: 10 Mar 2008 17:25
Reporter: Dayvison Pellegrina Email Updates:
Status: Not a Bug Impact on me:
None 
Category:Connector / ODBC Severity:S1 (Critical)
Version:3.5123 OS:Windows
Assigned to: CPU Architecture:Any

[10 Mar 2008 15:16] Dayvison Pellegrina
Description:
Hello guys,

 

I have a serius problem with a ASP application (Windows 2003 Server - IIS6) using MySQL(MyODBC 3.5123 - Database MySQL 5.041 at Linux Server :

 

Linux l30dnn0334 2.4.21-52.ELsmp #1 SMP Tue Sep 25 15:13:04 EDT 2007 i686 i686 i386 GNU/Linux

mysql  Ver 14.12 Distrib 5.0.41, for pc-linux-gnu (i686) using readline 5.0

 

 

When  I  try to connect the following error occurs:

Provider error '8000ffff' 

Catastrophic failure 

 

The line:

Conn.Open "Driver={MySQL ODBC 3.51 Driver};Server=*************;Port=3306; Option=16419;Stmt=;Database=****; Uid=****;Pwd=*****;  pooling=false"

The Windows server is with adequate memory and processing. Not detected overloads. The  process    W3wp.exe is in a maximum of 30% of CPU. We believe that is not  a hardware problem. 

 

The server Linux is less than 3% of CPU used. Regarding Hardware not detect problems too. 

 

We check our network and not detected problems. 

 

So we believe that the problem  can be many hits. The page has more than 500 thousand hits a day. Note some processes sleeping on the server, so I believe that the application programmer is not closing all connections,  would it be the problem? Does the driver MyODBC supports this whole quantity of requests? There are some specific configuration we can do? 

 

Thank you for your attention. 

 

Dayvison Pellegrina 

How to repeat:
The error is intermittent, sometimes occurs sometimes does not occur.
[10 Mar 2008 15:23] Tonci Grgin
Hi Dayvison and thanks for your report. I fear I can't do much without repeatable test case... Pooling is known culprit in IIS so you might google a bit to find ways of disabling it since putting "pooling=false" in connection string does *absolutely* nothing!

Are you by any chance running on Winx64? If so this is expected as there's no default OleDB provider for that platform yet.

You may also wish to check on netstat...
[10 Mar 2008 16:04] Dayvison Pellegrina
Thanks =D

Regarding the pool of connections, we will remove this syntax of the string of connection. As: 
Http://dev.mysql.com/doc/refman/5.0/en/myodbc-configuration-connection-parameters.html 

Meanwhile forgot to report that in the settings of the ODBC pool of connections is also off. 

Unfortunately we can not change the Win64x, meanwhile use a hardware and robust. Does the driver who does not support this amount of such requests? 

Unfortunately the problem is so unexpected and intermittent, so you won’t be able to test. But if you want send some source code, you can ask me. What we find is that when access is above average these errors occur when the access is the application works normally. 

Doubt: 
The fact that the connections are possibly getting open (not using the method. Close ()), can generate the error informed?

Thanks Again,
[10 Mar 2008 17:25] Tonci Grgin
Dayvison, I understood Spanish comment but it's better that you translated it to English as I might not be only one working on this.

So:
 1) "pooling" in connection string does nothing as driver ignores it and like many others depends on pool provided by framework
 2) "Meanwhile forgot to report that in the settings of the ODBC pool of connections is also off.": You mean in Driver Manager? That's not enough! Please search bugsdb on ODBC + pooling and see how to shut ODBC pool properly.
 3) But (!) main pooling problem comes from IIS! Please search internet / bugsdb to see how to properly shut down IIS pooling. This is very important as IIS is responsible for pooling mechanisms, not MyODBC (as you discovered when nothing changed when you removed "pooling=false" from connection string). You can get some hints in Bug#12274.

Again, probably stale connections are not released from pool by IIS and/or you are not checking them before reuse and/or pool can not accommodate such high traffic and/or MySQL server is configured so that it can't give you requested number of connections (you should be able to find out which scenario is in effect with netstat and "show processlist") ... but there is no bug in MyODBC here that I can see.