Join us this Friday for AI in Action at the Virtual Happy Hour! This free virtual event is open to all—enroll now on Academy and don’t miss out.
Join us this Friday for AI in Action at the Virtual Happy Hour! This free virtual event is open to all—enroll now on Academy and don’t miss out.
Does it help if you turn off session state? That's probably why you have to wait for the error to time out until you can request a new resource.
Why it's taking so long? Maybe you have an infinite loop, where an error keep redirecting you to the error page.
Thanks Johan. I will try out session state tomorrow.
It might be an infinitive loop but the strange thing is that I never have it on the dev environment.
Right now I am struggling with a even more strange thing.
I have change the type of a property from longstring to xhtmlstring and for one instance of that property on a page type I have a displaytemplate and for those pages this happens.
If I run in debug mode (F5) it all works.
If I run the same code on the same IIS Express without debug (CTRL + F5) it fails saying that it can't convert a string to xhtml.
I can catch the error if I CTRL F5 and after that attach the debugger to the IIS Express process but it not giving me mutch more to go on.
Solving this will become a struggle....
If you're not using Session, then it's best to turn it off http://msdn.microsoft.com/en-us/magazine/cc163730.aspx. We have it off by default in our templates.
Sadly we use sessions so we need it.
I will check out if there are a loop somewhere that I can not see
Henrik, did you find a solution for this issue in the end? We are experiencing the same on out EPiServer 9.8 solution.
Try setting the
<applicationSettings globalErrorHandling="Off"
and use a static 500 page...
Probably an infiinite loop that kills application pool...
Check here to catch it in event log (not shown by default...)
http://stackoverflow.com/questions/9984604/how-to-find-app-pool-recycles-in-event-log
Thank you very much Daniel, this has fixed our error! All working as expected now, really good news! Will have to remember using a static page for 500 in the future.
We have problem on our test and live servers that if there is a 500 error on a EPiServer-page, the session that request this page takes a very long time to get the response. We can see that it logs the error directly but it takes forever to get the 500-response from the server.
All other request to the same site, even to pages that works will never responde until the current thread is done/killed so it is very frustrated for the visitors. The good thing is that there are nearly never an error but when it happens.... ;-)
I have never been able to reproduce it in my local development site, there I get the error response directly.
Anyone else who has seen something like this?