This project is read-only.

Orchard Tenants Gone Wild - How to Terminate and Keep Server Up

Topics: Core, Customizing Orchard
Jun 2, 2014 at 6:28 PM
Yup, it has happened to me. Had a tenant using a module (to be named or corrected later) that had table locks on it causing this particular tenant to freak out and bring down all the tenants on this database. This shouldn't be the end of the world as, ideally, I would just go to the Tenant host and turn off the tenant then restart it. Well, things aren't that simple. The tenant won't turn off and it keeps retrying / throwing errors until I reboot the webserver (which of course brings down all my other tenants). I know, fix the module, file a bug, and move on. However, I am sure it will happen again. Is there anyway to "kill" a tenant that will absolutely work? That way I wouldn't have to drop all my tenants while the web server restarts. For perspective, this is on Azure SQL. Thanks for thoughts (and will file as a bug if it appears that is what it is).
Jun 2, 2014 at 10:45 PM
This sounds like the title of a bad porn parody :-). Even the second part.

If you can at least access the tenant edit page then you should be able to turn off the tenant: that will shut it down by terminating the shell and disposing the Autofac container - unless something can prevent this.
Jun 3, 2014 at 2:40 AM
I like to get creative with my titles, perhaps a bit too far ;-)

I can access the tenant edit page as I keep the default tenant on a separate (very small) database. I intentionally did this as I figured someday I would need to be able to terminate tenants if things lock. Unfortunately, terminating a crazy busy tenant doesn't succeed (so something must be preventing it). Was hoping for a kill switch that worked every time. Even when I delete the hrestart.txt file it doesn't force the connection (usually causes issues as I believe Orchard is trying to activate the tenant and it can't get through to the database which is bogged down). So should I request a more powerful kill switch as an issue? Hardest part is to recreate a scenario to test this...