Hi - I hope I'm not being a complete moron here, but does someone have an example for me of how to recycle or stop/start a UWS app via commandline or API?

I have a process that occasionally will update the content of a UWS app, and the site doesn't display correctly until a manual recycle.

P.S. If both ways exist, I'd love to know how to do both commandline and API.

Thanks!

We are having a similar problem with our deployment of the server. It seems to be particularly apparent when we change the web.config file while the server is running, but also crops up when other files are changed. We have received 404 errors when the server dies, and frequently get 503 errors. Is there a reason that changing these files would cause the monitoring service to crash? Is there a way we can prevent the service from crashing in the first place?

Hi there!

Is it possible that when you think monitoring service has crashed, it's just application's AppDomain is being recreated? Would you mind sending us Event Log entries capturing monitoring service crash?

Also, do you see these strange 404s and 500s only for limited period of time after application files were changed, or does the application remain in the broken state for more than 2 minute/permanently?

Here's a little bit of a background info. Each web application runs in an ASP.NET AppDomain. Our UWS.AppHost processes may host one or more such AppDomains - one AppDomain per app. When changes are made to web.config, content of Bin folder and in some other cases, ASP.NET unloads its AppDomain and tells the host - web server - to load the application into another AppDomain with updated configuration. This presents a few challenges for the web server design. If it was possible to listen to inbound requests outside of the application's AppDomain, like IIS does, then it would be possible to implement AppDomain start/retirement routine without a single request being lost - listener would just hold on to the request until application AppDomain is ready to process it. But due to HttpListenerXXX set of .NET Framework classes (used by UWS to process http requests) not being cross-AppDomain friendly, our web server has to listen to inbound requests inside the applications' AppDomains. This means that subsequent rapid changes to the application may create multiple AppDomain starts and retirements, creating a flurry of very expensive activities related to parallel loading/unloading of multiple AppDomains for the same application, which unfortunately leads to some requests being lost. On the plus side, not having to pass requests across AppDomain boundaries helps UWS performance quite significantly.

The bottom line is that with multiple rapid application file changes, which may cause multiple application load/unloads, 404 and 503 responses should go away shortly, and we won't be able to improve it much as .NET Framework HttpListener class limitations won't let us do better. This problem is significant if you observe that application remains in the broken state. Please let us know if that's the case.

Best regards,
UltiDev Team.

I don't get server errors, I get ASP.Net error messages stating custom control tags are not valid (I don't have the machine available right now to give you a more detailed answer, sorry). As soon as I recycle the app, it works perfectly. I'll try the app_offline.htm workaround and let you know.

P.S. Great product!

Thanks
James

Just to let you guys know this seems to have worked.

What sort of timeframe should I allow from the time the file is removed to when I should check when the app is up?

Thanks again for the great product!

James