We Keep Coding

LINQ to SQL timeout on one server and not other

I'm using LINQ to SQL to access a stored procedure. This works fine on my local sql server. But once I point to a different server within the internal network, I get a timeout. In SQL Profiler, I can see the query that is sent to the problem server. This should mean the query is hitting the server and executing right?
I can run the LINQ output directly on the problem server without issue. Is this probably not a code issue and instead some problem with the sql server server configuration? What should I check to troubleshoot it?

The connect timeout is different from the command timeout.
see: What is the difference between SqlCommand.CommandTimeout and SqlConnection.ConnectionTimeout?
The summary is connect timeout is the amount of time to establish a connection.
Command timeout is the amount of time to let the command run. Not just how long it takes to get the first record, but how long it takes to grab the entire dataset.
If you see the query showing up in SQL Profiler, then yes it is being sent. So you're essentially hitting the command timeout default limit of 30 seconds.
I would suggest starting with changing the command timeout to 500 and see where that takes you. Then I would start doing some performance analysis to determine why it takes that long. Maybe you can trim out some of the data requested or even add additional indexes to better support the query.

500 Internal Server Error With Ajax Request

hi guys,
Does anyone have any knowledge about the error seen at the image down below
The error occurs after waiting on the page for a while and then requesting an ajax call. The error is not repeated afterwards, but when the user waits again the error pops up again too. So the problem is about waiting on the page for a while, but could not find out why?
Thanks for the incoming responses
edit:link to image http://i53.tinypic.com/2ni8bcg.png

Well, basically an exception is occurring within your web service. It sounds like it's probably something timing out.
The first thing you should do is improve your logging (e.g. with ELMAH) so you can see exactly where the exception is being thrown... and then go about fixing it.
If it's a database connection timing out, it could be that you're forgetting to close the connection somewhere...

MySql.Data.MySqlClient.MySqlException: Timeout expired

In recent times, a particular page in my web app throws the
Exception Details: MySql.Data.MySqlClient.MySqlException: Timeout
expired. The timeout period elapsed prior to completion of the
operation or the server is not responding.
Though I use Ibtais as persistence layer, this error occurs. I have restarted the MySql service instance but stil i get the same error. It didn't happen earlier but happens frequently in recent times.
All the web applications deployed on the server uses Ibatis and the DB server remains on the same machine where IIS is installed. There are about 8000 records in which around 300 to 500 would be filtered on page load
Any insights for the cause of the problem?

I encountered the same problem with yours, and I found this MySQLConnection--Specifying default command timeout. Just add "default command timeout=xxx" into your connectString, this key's value is in seconds.
I tried and it worked for me.

You could set command timeout to 0, its not a good idea though. Some requests could go on indefinitely.
There is an underlying problem that is causing the queries to time out in the first place. Are you inserting, updating, or in any way working with large binary values that would lock the table? That is the most common reason I see for an error like this on such a small amount of data.

Make your connection string look like this:
DotNet Framework:
<add key="MYSQL_CONNECTION_STRING_RDS" value="Uid=userid;Password=pass;
Server=localhost;Port=3306;
Database=dbname;default command timeout=0;SslMode=none"
/>
DotNet Core
"MYSQL_CONNECTION_STRING_RDS": {
"ConnectionString": "Server=localhost;Database=dbname;user=userid;password=pass;default command timeout=0;",
"ServerVersion": "8.0.22"
}

Why does HttpWebRequest GetResponse block for such a long time?

I have some fairly simple code that uploads a photo or video to an endpoint (using HTTP PUT or POST). Every so often I see connection closed exceptions thrown, and in reality the photo/video was uploaded just fine, it's calling GetResponse where the exception occurs.
One thing I've noticed is that GetResponse can take an awful long time to process. Often longer than the actual upload time of the photo to the server. My code writes to the web server using RequestStream.Write.
I did a little test and uploaded about 40 photos/videos to the server that range in size from 1MB to 85MB and the time for GetResponse to return was anywhere from 3 to 40 seconds.
My question is, is this normal? Is this just a matter of how long the server I am uploading these files to is taking to process my request and respond? In looking at Fidder HTTP traces it seems to be the case.
FYI, my uploads are HTTP 1.0, Timeout values set to Infinite (both Timeout and ReadWriteTimeout)

If the server is genuinely taking a long time to return any data (as shown in Fiddler) then that's the cause of it. Uploading an 85MB attachment would take a long time to start with, and then the server has to process it. You can't do a lot about that - other than to use an asynchronous method if you're able to get on with more work before the call returns.
It's not entirely clear what Fiddler's showing you though - is it showing a long time before the server sends the response? If so, there's not much you can do. I'm surprised that the connection is being closed on you, admittedly. If, however, you're not seeing your data being written to the server for a while, that's a different matter.
Are you disposing the response returned? If not, you may have connections which are being kept alive. This shouldn't be a problem if it's explicitly HTTP 1.0, but it's the most common cause of "hanging" web calls in my experience.
Basically, if you don't dispose of a WebResponse it will usually (at least with HTTP 1.1 and keepalive) hold on to the connection. There's a limit to the number of connections which can be open to a single host, so you could end up waiting until an earlier response is finalized before the next one can proceed.
If this is the problem, a simple using statement is the answer:
using (WebResponse response = request.GetResponse())
{
...
}

Yes, the response time may be a lot longer than just the upload time. After the request has been sent to the server it has to be processed and a response has to be returned. There may be some time before the request is processed, and then the file typically is going to be saved somewhere. After that the server will create the response page that is sent back.
IIS handles only one request at a time from each user, so if you start another upload before the first one is completed, it will wait until the first one completes before it even starts to process the next.

How do you deal with transport-level errors in SqlConnection?

Every now and then in a high volume .NET application, you might see this exception when you try to execute a query:
System.Data.SqlClient.SqlException: A transport-level error has
occurred when sending the request to the server.
According to my research, this is something that "just happens" and not much can be done to prevent it. It does not happen as a result of a bad query, and generally cannot be duplicated. It just crops up maybe once every few days in a busy OLTP system when the TCP connection to the database goes bad for some reason.
I am forced to detect this error by parsing the exception message, and then retrying the entire operation from scratch, to include using a new connection. None of that is pretty.
Anybody have any alternate solutions?

I posted an answer on another question on another topic that might have some use here. That answer involved SMB connections, not SQL. However it was identical in that it involved a low-level transport error.
What we found was that in a heavy load situation, it was fairly easy for the remote server to time out connections at the TCP layer simply because the server was busy. Part of the reason was the defaults for how many times TCP will retransmit data on Windows weren't appropriate for our situation.
Take a look at the registry settings for tuning TCP/IP on Windows. In particular you want to look at TcpMaxDataRetransmissions and maybe TcpMaxConnectRetransmissions. These default to 5 and 2 respectively, try upping them a little bit on the client system and duplicate the load situation.
Don't go crazy! TCP doubles the timeout with each successive retransmission, so the timeout behavior for bad connections can go exponential on you if you increase these too much. As I recall upping TcpMaxDataRetransmissions to 6 or 7 solved our problem in the vast majority of cases.

This blog post by Michael Aspengren explains the error message "A transport-level error has occurred when sending the request to the server."

To answer your original question:
A more elegant way to detect this particular error, without parsing the error message, is to inspect the Number property of the SqlException.
(This actually returns the error number from the first SqlError in the Errors collection, but in your case the transport error should be the only one in the collection.)

I had the same problem albeit it was with service requests to a SQL DB.
This is what I had in my service error log:
System.Data.SqlClient.SqlException: A transport-level error has occurred when sending the request to the server. (provider: TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host.)
I have a C# test suite that tests a service. The service and DB were both on external servers so I thought that might be the issue. So I deployed the service and DB locally to no avail. The issue continued. The test suite isn't even a hard pressing performance test at all, so I had no idea what was happening. The same test was failing each time, but when I disabled that test, another one would fail continuously.
I tried other methods suggested on the Internet that didn't work either:
Increase the registry values of TcpMaxDataRetransmissions and TcpMaxConnectRetransmissions.
Disable the "Shared Memory" option within SQL Server Configuration Manager under "Client Protocols" and sort TCP/IP to 1st in the list.
This might occur when you are testing scalability with a large number of client connection attempts. To resolve this issue, use the regedit.exe utility to add a new DWORD value named SynAttackProtect to the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\ with value data of 00000000.
My last resort was to use the old age saying "Try and try again". So I have nested try-catch statements to ensure that if the TCP/IP connection is lost in the lower communications protocol that it does't just give up there but tries again. This is now working for me, however it's not a very elegant solution.

use Enterprise Services with transactional components

I have seen this happen in my own environment a number of times. The client application in this case is installed on many machines. Some of those machines happen to be laptops people were leaving the application open disconnecting it and then plugging it back in and attempting to use it. This will then cause the error you have mentioned.
My first point would be to look at the network and ensure that servers aren't on DHCP and renewing IP Addresses causing this error. If that isn't the case then you have to start trawlling through your event logs looking for other network related.
Unfortunately it is as stated above a network error. The main thing you can do is just monitor the connections using a tool like netmon and work back from there.
Good Luck.

You should also check hardware connectivity to the database.
Perhaps this thread will be helpful:
http://channel9.msdn.com/forums/TechOff/234271-Conenction-forcibly-closed-SQL-2005/

I'm using reliability layer around my DB commands (abstracted away in the repository interfaece). Basically that's just code that intercepts any expected exception (DbException and also InvalidOperationException, that happens to get thrown on connectivity issues), logs it, captures statistics and retries everything again.
With that reliability layer present, the service has been able to survive stress-testing gracefully (constant dead-locks, network failures etc). Production is far less hostile than that.
PS: There is more on that here (along with a simple way to define reliability with the interception DSL)

I had the same problem. I asked my network geek friends, and all said what people have replied here: Its the connection between the computer and the database server. In my case it was my Internet Service Provider, or there router that was the problem. After a Router update, the problem went away. But do you have any other drop-outs of internet connection from you're computer or server? I had...

I experienced the transport error this morning in SSMS while connected to SQL 2008 R2 Express.
I was trying to import a CSV with \r\n. I coded my row terminator for 0x0d0x0a. When I changed it to 0x0a, the error stopped. I can change it back and forth and watch it happen/not happen.
BULK INSERT #t1 FROM 'C:\123\Import123.csv' WITH
( FIRSTROW = 1, FIELDTERMINATOR = ',', ROWTERMINATOR = '0x0d0x0a' )
I suspect I am not writing my row terminator correctly because SQL parses one character at a time right while I'm trying to pass two characters.
Anyhow, this error is 4 years old now, but it may provide a bit of information for the next user.

I just wanted to post a fix here that worked for our company on new software we've installed. We were getting the following error since day 1 on the client log file: Server was unable to process request. ---> A transport-level error has occurred when receiving results from the server. (provider: TCP Provider, error: 0 - The semaphore timeout period has expired.) ---> The semaphore timeout period has expired.
What completely fixed the problem was to set up a link aggregate (LAG) on our switch. Our Dell FX1 server has redundant fiber lines coming out of the back of it. We did not realize that the switch they're plugged into needed to have a LAG configured on those two ports. See details here: https://docs.meraki.com/display/MS/Switch+Ports#SwitchPorts-LinkAggregation