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
accessing a previously running site crashes dispatcher #714
Comments
I've seen this crash before. So you're saying it's easily reproducible? |
Is that after the site was restarted? Otherwise I fail to see how the dispatcher would be able to dispatch to that particular host. |
I got a report for it, and reproduced it easily on my machine. The site was in state "stopped". Try it :p |
You are right. Just do z_sites_manager:stop(sitename). and then try reload the site; it will crash. On 13-02-14 13:29, Andreas Stenius wrote:
|
Finally managed to produce the stack trace:
|
Will look into it later, no time now |
Apparently the stopped site is still known to the dispatcher. |
Yes, so what's the best solution to fix this? |
Need to check - I think the dispatcher shouldn't "know" about any stopped site. |
indeed so we need to reload the dispatch info when a site starts and/or stops? or is that done already? |
I am not sure now, will have a look at it later. |
BTW, it crashes because |
Solution is good - efficiency of the dispatcher is something I want to tackle later anyway. (See also the GSoC 2014 list) |
👍 |
Fixes zotonic#714 This seems to be the most simple solution. Downside is that on Zotonic startup the dispatch rules are reloaded several times (for each starting site). (cherry picked from commit 6548399)
It doesn't matter if the site config says enabled true or false, only requirement is that the site was running, and then later was stopped.
Expected a 404, as it gives for a site that is disabled, and was never started.
The text was updated successfully, but these errors were encountered: