Semaphore Timeout Period

Question

I\'ve recently wiped and reinstalled/configured all the components of my web and DB servers. I\'m running IIS 6, .NET 3.5, SQL Server 2005. The two servers are separate VM\'

Answer 1

A few pointers are here .Basically the error is being thrown by the network layer and SQL server is just reporting it.

Hope that helps.

Answer 2

After troubleshooting this for hours and sitting on the phone with my hosting group they discovered that there was a problem with their networking configuration. The solution was made clearer when during my testing one of the VM's suddenly couldn't find the domain, and a simple 'ping' to the IP of each box from the other would occasionally time out. This ruled out DNS entirely. After the hosting group applied the proper configuration on their end the app has been stable and FAST!

Thanks for everyone's help!

Answer 3

I will post my experience just in case it might help someday somebody ;)

At the end of the year, just trying to connect remotely to our servers from a place far, far away, using my phone. I noticed that I could not login to one windows server via remote desktop (black screen), nor I could connect from a Windows Application to the same server.

As soon as I changed from my phone to a different connection (via a NightHawk M1 mobile router), it was all good.

As I have read, is is about NETWORKING issues mainly, so DO NOT PANIC and try to find the guilty there.

Hope it helps, R

Answer 4

Late to the game, but I was getting this same error with a .NET web app/MS SQL. Site hosted in IIS on GoDaddy VPS, hosting has multiple IPs, DB hosted at Azure.

I believe my problem was (idiot!), I simply forgot to put the GD site's dedicated IP addresses from GD into the Azure firewall for the SQL server. For some strange reason the traffic gets to/from GD/Azure outside of the actual IP address for the website (the IIS binding addresses) and works.

But more often than not the actual IIS binding addresses are the ones calling out to Azure to interact with the SQL services. I corrected the firewall settings on Azure to include the correct IPs from GoDaddy and (knock on wood) the semaphore error seems gone now.

In other words, before you start looking for big problems, start simple and be sure to check easy things like network/firewall settings.

Answer 5

check whether the stored procedure has any line SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED

For me this was the issue

Answer 6

Can you double check the load on the db server? We do get them once in a while in our dev env, but never in the prod env.