Bug #10637 Fail connect to specified MySql Hosts
Submitted: 14 May 2005 3:49 Modified: 25 Jun 2005 18:45
Reporter: Fei Wong Email Updates:
Status: Closed Impact on me:
Category:Connector / NET Severity:S2 (Serious)
Version:1.0.4 OS:Windows (Windows 2K/2003)
Assigned to: Reggie Burnett CPU Architecture:Any

[14 May 2005 3:49] Fei Wong
StreamCreator call socket connect asynchronously by calliing beginConnect(), which uses the system thread pool. When the client calls MySqlConnection.open() from a callback of MSMQ for receiving message, using delegate call back as well. This causes will result in a system thread waits for another system thread for socket connection. However, that thread pool has already been consumed. The final result is no meaning work can be done. Most of the connections fail to connect to MySql hosts.

How to repeat:
Use delegate's beginInvoke to call create MySqlConnection, open, read data and close continously.

Suggested fix:
Use sychronized connect method.
[19 May 2005 7:11] Vasily Kishkin
Could you please to send any test suit of this bug for better understaning the problem. Thanks.
[20 May 2005 11:27] Fei Wong
Test class for this bug

Attachment: Class1.cs (text/plain), 2.23 KiB.

[19 Jun 2005 23:00] Bugs System
No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[20 Jun 2005 0:38] Fei Wong
A simple test program is attached.
[20 Jun 2005 9:27] Vasily Kishkin
I was able to reproduce it. Thank for test case.
Tested on Win 2000 Sp4, Microsoft Visual C# .NET , Connector .NET 1.0.4
[24 Jun 2005 20:03] Reggie Burnett
Thank you for your bug report. This issue has been committed to our
source repository of that product and will be incorporated into the
next release.

If necessary, you can access the source repository and build the latest
available version, including the bugfix, yourself. More information 
about accessing the source trees is available at

Additional info:

Thanks for this bug report.  I have reworked how the connection is handled and it no longer uses a worker thread.
[24 Jun 2005 20:27] Reggie Burnett
The problem was that we were  using BeginConnect/EndConnect to implement connect	timeout. Each one of these uses a worker thread from the .NET thread pool.  This thread pool only has a default of 25 threads so on a very heavily loaded system, it's possible it could run out.  Connect has now been recoded to not use a worker thread.

This is fixed in 1.0.5
[25 Jun 2005 18:45] Mike Hillyer
Documented in 1.0.5 changelog.