Bug #13865 MySQl Conn. raises a wrong exception on connect
Submitted: 8 Oct 2005 15:34 Modified: 13 Oct 2005 21:20
Reporter: Federico Giampietro Email Updates:
Status: Closed Impact on me:
Category:Connector / NET Severity:S2 (Serious)
Version:1.0.6 OS:Server 2003
Assigned to: Reggie Burnett CPU Architecture:Any

[8 Oct 2005 15:34] Federico Giampietro
I'm migrating to version 1.0.6 and discovered that the connector raise this exception:

A non-blocking socket operation could not be completed immediately

when you open the connection.
I tested on my application, and verified with connector's testapp (TableEditor).

This exception come from the file SocketStream.cs in the Connect(EndPoint remoteEP, int timeout) function, at the marked point:

		public bool Connect(EndPoint remoteEP, int timeout)
			int err;
			// set the socket to non blocking
			socket.Blocking = false;

			// then we star the connect
				socket.Connect(remoteEP); <- *** HERE !!!! ***
			catch (SocketException se)
				if (se.ErrorCode != 10035 && se.ErrorCode != 10036)
					throw new MySqlException(Resources.GetString("ErrorCreatingSocket"), se);

			// next we wait for our connect timeout or until the socket is connected
			ArrayList write = new ArrayList();
			ArrayList error = new ArrayList();

			Socket.Select(null, write, error, timeout*1000*1000);

			if (write.Count == 0) 
				return false;

			// set socket back to blocking mode
			socket.Blocking = true;
			return true;

Regards, Federico.

How to repeat:
in the Visual Studio IDE, load TableEditor project, set the debugger to "go to debugger" for CLR exceptions,
compile&run the project.
[9 Oct 2005 11:39] Vasily Kishkin
Sorry...I was not able to reproduce the bug. TableEditor works fine. Could you please create your simple test case and attach it ?
[10 Oct 2005 8:19] Federico Giampietro
System description:

MySQL server: 5.13
O.S.: Server 2003 SP1
Hardware: 4 * Xeon 3GHz
[11 Oct 2005 9:38] Vasily Kishkin
I guess This is problem of SP1 of Windows 2003. Could you please test it on another Windows ?
[11 Oct 2005 17:22] Federico Giampietro
Not now, sorry.

[12 Oct 2005 11:52] Federico Giampietro
Tested on another system with 2 * Pentium III + Server 2003 SP1:
same result.
Sorry but here no 2003 without SP 1.
This is not a production server, but a developer machine. Then, if you like, I can give you a remote acces to the system and his developing environment using Remote Desktop to make some test.

Byte, Federico.
[13 Oct 2005 21:20] Reggie Burnett
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.mysql.com/documentation/ and the instructions on
how to report a bug at http://bugs.mysql.com/how-to-report.php

Additional info:


I believe you have VS.Net set to break on all exceptions instead of unhandled exceptions.  Because the socket class is brain dead in .NET, we are using an exception to implement async connect with timeout.  This is expected and is not a problem although not ideal.

If you feel differently, please let me know your thoughts.  We can discuss it further.
[13 Oct 2005 21:54] Federico Giampietro
Ok, tnx for explain, but I think this is a problem, because when a developer uses the debugger to debug his application, it stops on your exception.
I know that support async connect on .NET is hard (I implemented a complete socket class), but I think that your way is wrong. Try to use delegate instead.

Regards, Federico.
[14 Oct 2005 13:48] Reggie Burnett

First, it will only stop here if you have the debugger set to stop at all thrown exceptions instead of unhandled ones.  Most devs do not run like this.

Second, my original implementation used a delegate.  This doesn't work because in a heavily loaded system it quickly uses up all the threads in the thread worker pool and connections start failing.  The only other implementation strategy involves pinvoking to winsock.  I have a working implementation of that but I have not go around to making that work on Mono.
[14 Oct 2005 15:30] Federico Giampietro
Hello Reggie,
confirm thath my debugger is set to catch any exception.
This because I'm working on a very big application and often I need to stop on handled exceptions too.
No problem, I'll continue to debug with the old 1.0.5 (I think this relese uses delegate because all is ok).

Bye, Federico.