New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
On /bin change models fail to compile and end up in an unhandled exception/YSOD #127
Comments
No idea what causes it, but seeing it on other Cloud sites. Looking into it. |
Another log:
Because the exception comes from |
Looking at
So, locking the |
Readings:
These explain what happens when a thread aborts, but not why a thread would abort while trying to |
Notes: It could be that the thread is being aborted due to timeout, depending on the value of
in |
About the Now need to figure out why we end up in a timeout, especially here in |
See PR #136 which tries to refactor the locks in |
@zpqrtbnk We are receiving this in Umbraco 7.5.4. We are not sure what triggers this, as no deployments or doc type updates are being made prior to these log entries, however we do have several scheduled tasks (content syncs) that are called frequently via custom surface controller URLs that could possibly be interfering somehow if they happen to run at the same time as the model builder? In our specific Azure web app environment, this (deadlock?) is actually causing the entire site (including the umbraco backend) to become unresponsive until we restart the site. Note that these messages occur every minute until the reset.
|
Review logs in PureLiveModelFactory [#127]
I have merged the PR, which should be more robust WRT locks. Also, next version of Core (7.5.12) will ship with a feature that auto-creates a (limited) number of process minidumps on Minidumps should show in I'm keeping this issue open. |
Not sure how to replicate but seen it on my site a few times when deploying and something in the /bin changes.
Here's the log which shows the initial /bin change, then it will YSOD, i changed the web.config debug to 'true', then it got 'stuck' for about 5 mins, assuming it's waiting for MainDom, then eventually it boots.
The text was updated successfully, but these errors were encountered: