locked
timing out on deployment RRS feed

  • Question

  • User759549661 posted

    Hi folks,

    First, my tale of woe. I have been publishing updated versions of my new website successfully recently, but last evening I had trouble, even though the upload settings are the same. I publish from Visual Studio 2017. On publishing, it said "Publish Succeeded". But when “Publish” tried to open the website at the end, I got the attached timeout error. I did get a message from VS after the publish attempt that said that my application .dll.config “has been changed externally, and has no unsaved changes inside this editor. Do you want to reload it?”. I just closed the window, no knowing which of the yes/no alternatives I wanted.  The website looked (and still looks) fine in localhost. The website when opened from a browser was still working, so I immediately made a backup via Plesk. I contacted my ISP, thinking the problem could be at their end, who responded “The server and the services are up and running fine. Further, we were able to access the database server using the credentials in the connection string without any issue. Unfortunately, coding and development are outside our scope of support”, which I get. I again tried opening the website from a browser, but this time got the timeout error. I restored the backup from Plesk, and the website now works. There were however warnings after the restore: “psadumpagent.InformationalException: Unable to restore MS-SQL database” then named the user database, then “Exclusive access could not be obtained because the database is in use. RESTORE DATABASE is terminating abnormally.”

    I suspect from the stack trace of the timeout error that the newly published website was having trouble connecting with the SQL databases behind it. I do have a data connection to those databases via VS, but they have red Xs on them unless I open them from VS Server Explorer, so the connection is not permanently open. I did make some changes to data in one of the databases before the publish attempts, so there could conceivably have been an open connection at that point. It also was the case that I was logged in to the website (though the website was closed) when I tried to do the publish: after restoration, I was still logged in. So my questions are:

    1. If the website publishes fine to localhost, and “Publish” says “Publish Succeeded”, doesn’t that mean that the coding is OK? I had made a change to Web.config (within VS, and saved): I had changed <customErrors mode="Off"/> to <customErrors mode="RemoteOnly" defaultRedirect="~/Error.aspx"/>, and had created an error page. I tried changing it back, and re-publishing, but got the same timeout error. The only other change I had made was to log exceptions by writing to a text file, by adding a call to an exception utility that appended the exception details to a text file after Catch exp (in all the Try .. Catch statements).
    2. How might I have inadvertently made changes to my .dll.config file? When offered the choice to load or reload, what considerations go into that choice? Is this likely to be connected to the failure to publish?
    3. Is the failure to restore the user database connected to the fact that I was logged in on the website, even though no web page was open? At present users stay logged in when they close the web page, unless they have clicked on “Log out”. (I would like to automatically log people out when they close the web page – is there an easy way to do that?). Could this also be connected to the failure to publish? Should I suspend the website in Plesk before publishing an update to it? Would this automatically give me exclusive access to the databases?
    4. Could the failure to publish be related to an open connection to the SQL database in VS?
    5. What else (apart from 1-4) do you think could have contributed to the failure to publish?

     

    I realize that one approach would be to test out each of these possibilities by trial and error, rolling back all my changes, etc. But I’m looking for an ounce of two of insight to point me in the right direction. I need to know what to avoid, when doing a publish. I don’t want users to be seeing any more error screens than necessary while I try to sort this out.

    Any insights would be greatly appreciated!

    Rob

    PS the full first line of the stack trace is:

    [SqlException (0x80131904): Connection Timeout Expired.  The timeout period elapsed during the post-login phase.  The connection could have timed out while waiting for server to complete the login process and respond; Or it could have timed out while attempting to create multiple active connections.  The duration spent while attempting to connect to this server was - [Pre-Login] initialization=13; handshake=43; [Login] initialization=0; authentication=0; [Post-Login] complete=14785; ]

    timeout error

    The notification I got from VS:

    The file has been changed

    Saturday, July 4, 2020 9:26 PM

Answers

  • User-1330468790 posted

    Hi MPT79,

    Yes, the only way to solve the problem is to test out each of possibilities since we have no idea about your project/codes, etc.

     

    You could try to Run SQL Profiler to target the problem

    What I could suggest you are some  as this stack overflow thread gives: typical problem when you get connection timeouts

    Since your provider responded: the connection is working using the credential. The problem might be the option#5. You could run SQL Profiler to see what actually happens during the sql execution.

     

    Here is another possible solution for you as the exception message is similar to yours.

    You could check if your case is a problem of "No Enough Memory". 

    1. You may have "Auto Close" enabled: Auto Close can have exactly this behavior, however it is rare for it to be turned on. To check this, in SSMS right-click on your application database, select "Properties", and then select the "Options" pane. Look at the "Auto Close" entry and make sure that it is set to False. Check tempdb also.

    2. SQL Agent Jobs may be causing it: Check the Agent's History Log to see if there were any jobs consistently running during the events. Remember to check maintenance jobs too, as things like Rebuilding Indexes are frequently cited as performance problems while they are running. These are unlikely candidates now, only because they would not normally be affected by the Profiler.

    More details, you could refer to : Help troubleshooting SqlException: Timeout expired on connection, in a non-load situation

     

    BTW, I could not see the picture you posted on this thread. Could you please share the image again?

    If you are not sure about how to insert image in the thread, you could refer to this thread.

    Though it is not marked as answer, I am 100% sure that it is working.

     

    Hope this can help you.

    Best regards,

    Sean

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Monday, July 6, 2020 7:42 AM

All replies

  • User-1330468790 posted

    Hi MPT79,

    Yes, the only way to solve the problem is to test out each of possibilities since we have no idea about your project/codes, etc.

     

    You could try to Run SQL Profiler to target the problem

    What I could suggest you are some  as this stack overflow thread gives: typical problem when you get connection timeouts

    Since your provider responded: the connection is working using the credential. The problem might be the option#5. You could run SQL Profiler to see what actually happens during the sql execution.

     

    Here is another possible solution for you as the exception message is similar to yours.

    You could check if your case is a problem of "No Enough Memory". 

    1. You may have "Auto Close" enabled: Auto Close can have exactly this behavior, however it is rare for it to be turned on. To check this, in SSMS right-click on your application database, select "Properties", and then select the "Options" pane. Look at the "Auto Close" entry and make sure that it is set to False. Check tempdb also.

    2. SQL Agent Jobs may be causing it: Check the Agent's History Log to see if there were any jobs consistently running during the events. Remember to check maintenance jobs too, as things like Rebuilding Indexes are frequently cited as performance problems while they are running. These are unlikely candidates now, only because they would not normally be affected by the Profiler.

    More details, you could refer to : Help troubleshooting SqlException: Timeout expired on connection, in a non-load situation

     

    BTW, I could not see the picture you posted on this thread. Could you please share the image again?

    If you are not sure about how to insert image in the thread, you could refer to this thread.

    Though it is not marked as answer, I am 100% sure that it is working.

     

    Hope this can help you.

    Best regards,

    Sean

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Monday, July 6, 2020 7:42 AM
  • User759549661 posted

    Sean, thanks so much for your suggestions.

    It turned out that the problem was solved by suspending the website and then reactivating it. After reactivation, I can publish as before, and the website seems to be back to normal. I did test the impact of someone being logged on to the website when I do a "hot" upload, and it did not seem to create a problem. But I do suspect it was some kind of error I introduced by possibly having an active connection to the website databases via VS at the time I did a "hot" upload, but I am gunshy of testing that out.

    I have uploaded the images of the stack trace and also of the strange notice I got from VS.

    Thanks again for your help. I greatly appreciate it.

    Rob

    Monday, July 6, 2020 4:02 PM
  • User759549661 posted

    Hi folks again,

    I still have the problem. I am still wondering if the timing out issue is at the ISP, because it appears to be resolved either by suspending the website on Plesk and then re-activating, or by restoring the website in Plesk from a back-up. Either of these restores the website to normal function for a while (few hours to 1 day?), but then it reverts to the timing out behavior. I have also tried publishing an earlier version of the website that had no timing out issues: it also worked at first, but then reverted to the timing out behavior, just like my most recent website. While it is working, the website appears to be fully functional. So I don’t think there is a coding issue.

    Is it possible that the tests they ran showed no issues because at that time there were none? Unfortunately I have not been able to identify any event that causes the timing out. But this morning I did experience something similar. I was checking the connection to the databases in VS Server Explorer, but when I tried to expand the database tables I got a “pre-login handshake error”, or a “Connection timeout expired” error. But then later I checked again, and the connection succeeded. I was then able to view the tables in either database. This is independent of the website. But the errors were very similar to that reported when the website times out. This also suggests to me that this is not a coding issue with the website.

    Finally: yesterday I restored the site, and it was working. This morning it was timing out. I restored it again. As I write this, several hours later it has now reverted to timing out (same stack trace as originally). I again checked the connection in VS Server Explorer, and I again get a timeout error (now identical to the website stack trace) on one of the databases (see image below).

    My question: Am I right in thinking that the above evidence exonerates the code? If so, is this something that my ISP should be expected to resolve? If not, I will explore this further myself, along the lines suggested by Sean.

    Rob

    Server Explorer timeout

    Thursday, July 9, 2020 5:50 PM
  • User759549661 posted

    You are the man Sean! My web host gave me admin permission to set Auto Close to False on one of the two databases (I'm not sure why only one), and that did the trick! I'm wondering if the cause was something to do with a change in their load balancing policy, since my website is not yet intended to attract visitors.

    Wednesday, July 15, 2020 1:57 PM