We have an umbraco 7.1.8 website running as a single instance Azure Web App, and sporadically get this error.
At this moment the website is down completely?
Web host html message not available.
________________________________________
Timeout expired. The timeout period elapsed prior to obtaining a connection from the pool. This may have occurred because all pooled connections were in use and max pool size was reached.
Exception Details:
umbraco.DataLayer.SqlHelperException: Umbraco Exception (DataLayer): SQL helper exception in ExecuteReader ---> System.InvalidOperationException: Timeout expired. The timeout period elapsed prior to obtaining a connection from the pool. This may have occurred because all pooled connections were in use and max pool size was reached.
at System.Data.ProviderBase.DbConnectionFactory.TryGetConnection(DbConnection owningConnection, TaskCompletionSource`1 retry, DbConnectionOptions userOptions, DbConnectionInternal oldConnection, DbConnectionInternal& connection)
at System.Data.ProviderBase.DbConnectionInternal.TryOpenConnectionInternal(DbConnection outerConnection, DbConnectionFactory connectionFactory, TaskCompletionSource`1 retry, DbConnectionOptions userOptions)
at System.Data.SqlClient.SqlConnection.TryOpenInner(TaskCompletionSource`1 retry)
at System.Data.SqlClient.SqlConnection.TryOpen(TaskCompletionSource`1 retry)
at System.Data.SqlClient.SqlConnection.Open()
at Microsoft.ApplicationBlocks.Data.SqlHelper.ExecuteReader(String connectionString, CommandType commandType, String commandText, SqlParameter[] commandParameters)
at umbraco.DataLayer.SqlHelpers.SqlServer.SqlServerHelper.ExecuteReader(String commandText, SqlParameter[] parameters)
at umbraco.DataLayer.SqlHelper`1.ExecuteReader(String commandText, IParameter[] parameters)
--- End of inner exception stack trace ---
at umbraco.DataLayer.SqlHelper`1.ExecuteReader(String commandText, IParameter[] parameters)
at umbraco.cms.businesslogic.CMSNode.setupNode()
at umbraco.cms.businesslogic.relation.Relation..ctor(Int32 Id)
at umbraco.cms.businesslogic.relation.Relation.GetRelationsAsList(Int32 NodeId)
at umbraco.cms.businesslogic.relation.Relation.GetRelations(Int32 NodeId)
at ASP._Page_Views_Shared_Header_cshtml.Execute() in d:\home\site\wwwroot\Views\Shared\Header.cshtml:line 13
at System.Web.WebPages.WebPageBase.ExecutePageHierarchy()
at System.Web.Mvc.WebViewPage.ExecutePageHierarchy()
at System.Web.WebPages.WebPageBase.ExecutePageHierarchy(WebPageContext pageContext, TextWriter writer, WebPageRenderingBase startPage)
at Umbraco.Core.Profiling.ProfilingView.Render(ViewContext viewContext, TextWriter writer)
at System.Web.Mvc.Html.RenderPartialExtensions.RenderPartial(HtmlHelper htmlHelper, String partialViewName)
at ASP._Page_Views_Layout_cshtml.Execute() in d:\home\site\wwwroot\Views\Layout.cshtml:line 114
at System.Web.WebPages.WebPageBase.ExecutePageHierarchy()
at System.Web.Mvc.WebViewPage.ExecutePageHierarchy()
at System.Web.WebPages.WebPageBase.ExecutePageHierarchy(WebPageContext pageContext, TextWriter writer, WebPageRenderingBase startPage)
at System.Web.WebPages.WebPageBase.RenderSurrounding(String partialViewName, Action`1 body)
at System.Web.WebPages.WebPageBase.PopContext()
at System.Web.WebPages.WebPageBase.RenderSurrounding(String partialViewName, Action`1 body)
at System.Web.WebPages.WebPageBase.PopContext()
at Umbraco.Core.Profiling.ProfilingView.Render(ViewContext viewContext, TextWriter writer)
at System.Web.Mvc.ViewResultBase.ExecuteResult(ControllerContext context)
at System.Web.Mvc.ControllerActionInvoker.<>c__DisplayClass1a.b__17()
at System.Web.Mvc.ControllerActionInvoker.InvokeActionResultFilter(IResultFilter filter, ResultExecutingContext preContext, Func`1 continuation)
at System.Web.Mvc.ControllerActionInvoker.InvokeActionResultFilter(IResultFilter filter, ResultExecutingContext preContext, Func`1 continuation)
at System.Web.Mvc.ControllerActionInvoker.InvokeActionResultFilter(IResultFilter filter, ResultExecutingContext preContext, Func`1 continuation)
at System.Web.Mvc.ControllerActionInvoker.InvokeActionResultWithFilters(ControllerContext controllerContext, IList`1 filters, ActionResult actionResult)
at System.Web.Mvc.Async.AsyncControllerActionInvoker.<>c__DisplayClass25.b__22(IAsyncResult asyncResult)
at System.Web.Mvc.Controller.<>c__DisplayClass1d.b__18(IAsyncResult asyncResult)
at System.Web.Mvc.Async.AsyncResultWrapper.<>c__DisplayClass4.b__3(IAsyncResult ar)
at System.Web.Mvc.Controller.EndExecuteCore(IAsyncResult asyncResult)
at System.Web.Mvc.Async.AsyncResultWrapper.<>c__DisplayClass4.b__3(IAsyncResult ar)
at System.Web.Mvc.MvcHandler.<>c__DisplayClass8.b__3(IAsyncResult asyncResult)
at System.Web.Mvc.Async.AsyncResultWrapper.<>c__DisplayClass4.b__3(IAsyncResult ar)
at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
Could this be because we are still using some old snippets like this:
`var relatedPages = library.GetRelatedNodes(this.Model.Content.Id) '
We had this problem before on a live environment. It happened when we used the ExecuteReader from the (oldish) Microsoft.ApplicationBlocks helper in some of our custom code.
We end up closing and disposing all connections in our custom code. To solve this for your case, I'm afraid it might require modifing the Umbraco core to apply this to all calls to the ExecuteReader method.
That happened to me before for similar reasons (unclosed SQL connections). It so happened the problem was in my custom code, and not in Umbraco's code. I tracked down the problematic code by searching for all code that created SQL connections, then modified the connection string to give each of them a unique name (a feature of SQL Server is that your connections can be named), then you can perform a query to see all open connections and their names.
That query will show you which part of your code is not properly closing connections.
Also note that I found this to be a problem on production, but not on my dev environment. The reason being that IIS (or maybe Windows Server) intentionally avoids performing garbage collection as much as possible. On your local development environment, those SQL connections are closed because they are garbage collected. On production, they are not garbage collected as often, so they stay open.
This may have occurred because all pooled connections were in use and max pool size was reache
We have an umbraco 7.1.8 website running as a single instance Azure Web App, and sporadically get this error.
At this moment the website is down completely?
Could this be because we are still using some old snippets like this: `var relatedPages = library.GetRelatedNodes(this.Model.Content.Id) '
We had this problem before on a live environment. It happened when we used the ExecuteReader from the (oldish) Microsoft.ApplicationBlocks helper in some of our custom code.
This was due to the fact that the connections created by ExecuteReader seemed to be not propely closed and the application pool could not free enough connections in time. See https://social.msdn.microsoft.com/Forums/en-US/e43f44f3-8db3-413d-a9a3-eaa1dc4f038c/max-pool-has-been-reached
We end up closing and disposing all connections in our custom code. To solve this for your case, I'm afraid it might require modifing the Umbraco core to apply this to all calls to the ExecuteReader method.
That happened to me before for similar reasons (unclosed SQL connections). It so happened the problem was in my custom code, and not in Umbraco's code. I tracked down the problematic code by searching for all code that created SQL connections, then modified the connection string to give each of them a unique name (a feature of SQL Server is that your connections can be named), then you can perform a query to see all open connections and their names.
That query will show you which part of your code is not properly closing connections.
Also note that I found this to be a problem on production, but not on my dev environment. The reason being that IIS (or maybe Windows Server) intentionally avoids performing garbage collection as much as possible. On your local development environment, those SQL connections are closed because they are garbage collected. On production, they are not garbage collected as often, so they stay open.
Since the error seems to always happen in the same piece of code
at ASP.PageViewsSharedHeader_cshtml.Execute() in d:\home\site\wwwroot\Views\Shared\Header.cshtml:line 13
and nowhere else, we're going to replace this piece of code and hope for the best.
is working on a reply...