Closed PiemP closed 6 months ago
I have the same behavior on my IIS. Sometimes, the IIS pool restarts, and it don't find some liquid or cshtml views. If we create a template in BO with the same name, it no longer crashes. This only concerns views with customized shapes. "Classic" views work well. Just restart the pool and everything is back to normal.
@pchoisnard are you on a OutOfProcess
mode? Have you create more than one site and application pool to serve the same Orchard Core installation?
I'm a bit ashamed.
About 5 months ago I have an issue with my IIS that given an error (I can't remember the code) when I restart the server, that I could not solve. To "fix" this, I have split the tenant over multiple sites and multiple application pools that point at the same Orchard Core installation. With this trick IIS seems working.
Until 1.4.0 all working, but now seems something can't do the same work as before: seems something related to concurrency. I have tried to increment the server RAM, but for now, the random error in the first message of this issue remains.
Hello. I don't know for the OutOfProcess, it can be seen at what level?
For each site on the same server I have a different pool running and, I have several domain names that point to the same application but different tenants.
I already had the problem in 1.3.0 Some of these sites are public and scanned by robots. I have a feeling that when IIS decides to restart a pool and the site is scanned, there may be a memory issue that explains this. But I don't see anything in the system logs.
I might try the solution of creating multiple pools for different url tenant to see if that continues.
I don't know for the OutOfProcess, it can be seen at what level?
You can see it in your web.config, if you have a line similar to this:
<aspNetCore processPath="dotnet" arguments=".\It.Csc.OrchardCorePA.CMS.dll" hostingModel="OutOfProcess">
Kestrel
answer to the requests that goes to yours OrchardCore installation and IIS
works as a reverse proxy. In the other case IIS
do all the job for you.
Another way to check it, is to look at the Network
tab in your browser developer tools... in the Response Header
have to find the server
header that can report who have produced the page: Kestrel or IIS.
Thanks. I have InProcess for my configuration.
With OutOfProcess it's better for you ?
I have two site with this feature, I can try OutOfProcess on one.
With OutOfProcess it's better for you ?
Honestly...(I'm ashamed) I don't know... for me is difficult to understand IIS and its problems and I prefer to work with Kestrel.
Thanks. You give me some ideas for testing things.
The only thing is that it's random, you shoul'd wait a while before knowing if it works :)
Does this still occur?
for me, doesn't happen anymore. Thank you.
Great, thank you. Closing it, then.
Describe the bug
I have a strange error in my production envirnment. When the IIS's server restart or an application pool goes in recycle some tenants (not all the one's related to the application pool) give me an error 500 when I try to navigate the frontend views.
Looking at the log files I found this:
SocialMedia-Header
andContent-FooterColumns
are liquid templates but the issue seems happen casually over liquid templates (before this exception I have experimentend another exception like this on another liquid template that is related to a different module). To solve the issue I have to wait a lot of time or reload the tenant in the interface that allow to manage the tenants. I don't have this problem in the development environment, I suppose, because in this environment I don't have all the tenants that I have in production.Production environment
Windows server 2019 IIS 10.0.17763.1 dotnet hosting bundle 6.0.9
OrchardCore 1.4.0 is deployed as an OutOfProcess application.
To Reproduce
I don't have a punctual test case. I suppose this could be dependant by server hardware. Try to prepare an OrchardCore SaaS instance with 100 tenants and some modules with liquid template but is not enought and probably could be difficult to repro it.
Expected behavior
no error in frontend.