Is there anything in the .NET MySqlClient (6.9.5.0) where when a MySQL server in the server pool is not responding (possibly due to temporary network issues), the server gets blacklisted or bypassed permanently? In our logging, we notice that an authentication error is thrown:
MySql.Data.MySqlClient.MySqlException (0x80004005): Authentication to host '<HOST>' for user '<USER>' using method 'mysql_native_password' failed with message: Reading from the stream has failed. ---> MySql.Data.MySqlClient.MySqlException (0x80004005): Reading from the stream has failed. ---> System.IO.EndOfStreamException: Attempted to read past the end of the stream.
Immediately after this error occurs, every attempt to write or read from the database fails, with this error message:
MySql.Data.MySqlClient.MySqlException (0x80004005): No available server found.
Any ideas? When the DB server was moved to be on the same host that our application is running on, the problem no longer occurs.
Two things strike me here:
The nature of your exception: System.IO.EndOfStreamException:
Attempted to read past the end of the stream.
And the fact that when the DB is located on the same machine as the
calling application, you do not encounter the issue.
To me, that's telling me that a transport or network related error is occurring, which is interrupting your stream. Once that occurs, your connection is reset, so subsequent calls to the DB are failing.
I would try to catch the EndOfStreamException, and attempt to gracefully close and reopen the connection. Something like below. If this allows subsequent calls to succeed, then you've found the issue... although keep in mind that in this structure the original call (within the try block) does not get called again. You will also need to properly need to recreate and open your connection on before making subsequent calls, since it is now always being disposed in the finally block.
try
{
//your work
}
catch (System.IO.EndOfStreamException ex)
{
System.Diagnostics.Debug.WriteLine("Stream exception caught: " + ex.Message.ToString());
}
finally
{
if(myConnection != null)
{
myConnection.Close();
myConnection.Dispose();
}
}
Related
When I try to access (open a connection to) an offline sql server instance (service turned off) from my web service, no exception is thrown, just a brief 5 sec timeout followed by return (I put the breakpoint way out in my controller, not sure what the connection object returns yet during the call to open).
I'm trying to simulate a scenario where the DB is not available to the webservice, and figured an exception would be thrown and I could just log the error.
Any suggestions on how to properly detect DB connection issues (I'm guessing I need to look to see what the connection object returns when calling open). It'd be nice to just have an exception bubble up though.
Thanks.
A connection timeout will be thrown for sure unless your thread is being aborted before that by a web server timeout. Placing a try/catch in your controller would certainly catch the DB connection timeout.
You should post code, as SqlConnection.Open() definitely would throw an exception but if you're using some other call/code to open the connection and it's getting swallowed then it is obviously difficult to determine a root cause.
My guess is that you are getting back a Connection object that is not connected, to check if it's connected:
if (conn.State == ConnectionState.Closed)
{
...
}
I'm making a webform that will go to a site, grab the rss feeds in xml format and read them into a XmlTextReader to be formated and displayed in my site.
I have this line which takes care of the reaching the other site
XmlTextReader reader = new XmlTextReader(#"http://www.wired.com/threatlevel/feed/");
When I run this from my localHost it runs fine. But once it gets publish on a 1and1 server it fails with the following error.
A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond 72.246.94.16:80
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.Net.Sockets.SocketException: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond 72.246.94.16:80
Source Error:
An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.
Any ideas what can it be?
Many Thanks!
You're probably being blocked by an outbound firewall at 1&1.
Contact 1&1 and ask them to disable it, or switch to a better host. (you get what you pay for)
I am writing a WinCE app in C# that makes an HTTP POST to an APACHE server residing on my network. Because of some network issues (I am guessing), I get the following exception in the managed code
System.Net.Sockets.SocketException occurred
Message="A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond"
ErrorCode=10060
NativeErrorCode=10060
StackTrace:
at System.Net.Sockets.Socket.ConnectNoCheck(EndPoint remoteEP)
at System.Net.Sockets.Socket.Connect(EndPoint remoteEP)
at System.Net.Connection.doConnect(IPEndPoint ep)
at System.Net.Connection.connect(Object ignored)
at System.Threading.ThreadPool.WorkItem.doWork(Object o)
at System.Threading.Timer.ring()
This exception isn't always thrown, but when it is thrown, my app fails to connect to the server AT ALL. Repeated connection attempts don't help in reconnecting either. The only thing that helps is closing and re-deploying the app.
I can't catch the exception because its inside of managed code. Is there any way to circumvent this and close all socket connections to my server and re-initialize them? Is there something I am doing wrong?
The exception message looks a bit misleading ("connection attempt failed because the connected party") but I think it means your hardware is communicating with the server, but the server is not accepting the connection on the TCP level.
A problem I could think of is "hanging" connections, causing the server to reach the maximum number of concurrent connections and to stop accepting new ones.
Although it's just a guess, you might want to check the apache log if you can to see if you can find out if the server reports anything, and perhaps try restarting apache as soon as the problem occurs again. If that helps, you still need to find the cause of course.
We're using WebClient, .NET 3.5sp1 in a winforms application. For some users this results
in an Exception with the message:
"The underlying connection was closed: A connection that was expected to be kept alive was closed by the server."
Searching a bit around the web suggests a "fix" to just disable http keepalive, which we're not really interested in doing, some suggests it might be a bug in the .NET libraries, etc.
The error message suggests it's a keepaliv'ed http connection that somehow got closed by the server(or a proxy) without the underlyings of WebClient detecting it properly.
We're thinking of catching this specific case, and simply try the request again. However we cannot reproduce this exception. So.
How can we properly catch the case that yields the above error message.
catch(WebException ex) {
if (ex.Message == "The underlying connection was closed: A connection that was expected to be kept alive was closed by the server") { ... }
smells.. bad.
Any tips on how we can reproduce the above exception ?
WebClient detects this just fine. Thus the exception. You need to find the server that's misbehaving. Not quite sure what to do if you find that server, maybe you can send the admin a nice email message.
Log the server URL.
I suggest you have a look at this blog by Misrosoft: Http Client Protocol Issues
Good afternoon,
I am running into a curious problem with WCF and IntelliTrace. I have an application that I'm testing using a locally-hosted WCF endpoint (the development server built into VS2010) using the basicHttpBinding. The application has been running normally: no exceptions are are making their way to the app and all of the WCF calls are returning data.
On a lark, I decided to take a look at the IntelliTrace output and noticed that my first call to WCF throws two exceptiosn:
Exception:Thrown: "No connection could be made because the target machine actively refused it" (System.Net.Sockets.SocketException)
A System.Net.Sockets.SocketException was thrown: "No connection could be made because the target machine actively refused it"
Exception:Caught: "No connection could be made because the target machine actively refused it" (System.Net.Sockets.SocketException)
A System.Net.Sockets.SocketException was caught: "No connection could be made because the target machine actively refused it"
I've reduced the application to a trivial use case:
ServiceClient client = new ServiceClient();
string[] output = client.LegacyCheck("username");
Console.WriteLine(output[0]);
Console.WriteLine(client.GetData(65));
And I get the same behavior. The second call has no exception associated with it.
I'm very puzzled. If the connection is being refused, then why does the exception not make it up to the application? And why would it success after 2 failed tries?
Any help is appreciated!
For what it's worth, I've noticed this behavior too with my IronPython/WPF applications. I've eventually realized that Intellitrace is simply showing you ALL of the exceptions that are raised and caught during normal operation, even if its part of a BCL or other library.
Of course, you only need to worry about unhandled exceptions (after they break your execution, you'll usually see those in IntelliTrace as a long chain of Thrown: Caught: Thrown: Caught: .... all the way down to Thrown: which will be the last line as the exception was not caught.
What I'm willing to bet is that the WCF code try's a couple of things first, catches the SocketExceptions, and then continues on its merry way. You wouldn't ever see this, but for IntelliTrace :)