Welcome Guest! To enable all features please Login or Register.

Notification

Icon
Error

Recycling from API or Command Line
Jimi
#1 Posted : Wednesday, August 1, 2012 4:28:19 AM(UTC)
Groups: Member
Joined: 8/1/2012(UTC)
Posts: 1
Location: Johannesburg

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!
Ultidev Team
#2 Posted : Wednesday, August 1, 2012 10:09:25 AM(UTC)
Ultidev Team

Groups: Administration
Joined: 11/3/2005(UTC)
Posts: 2,253

Thanks: 28 times
Was thanked: 60 time(s) in 59 post(s)
Hello, Jimi.

There is no way to restart an application. We simply need to figure out why updated content is not served. Could you tell us please what exactly happens when "the site doesn't display correctly"? Do you get 404, old content or something else?

It's always helpful to run Fiddler to see what happens on the wire. If you get 304 (serve from cache), it's one thing. If you get old content, it's another. To help you wee need to understand better what exactly is going on.

Best regards,
UltiDev Team.
Please donate at http://www.ultidev.com/products/Donate.aspx to help us improve our products.
Guest
#3 Posted : Thursday, August 2, 2012 10:42:08 AM(UTC)
Groups: Member
Joined: 11/1/2005(UTC)
Posts: 278

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?
bkrupa21
#4 Posted : Thursday, August 2, 2012 10:44:45 AM(UTC)
Groups: Member
Joined: 8/2/2012(UTC)
Posts: 1
Location: Pittsburgh

Guest;3917 wrote:
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?


Sorry, this post was from me. Forgot to login.
Ultidev Team
#5 Posted : Thursday, August 2, 2012 11:10:04 AM(UTC)
Ultidev Team

Groups: Administration
Joined: 11/3/2005(UTC)
Posts: 2,253

Thanks: 28 times
Was thanked: 60 time(s) in 59 post(s)
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.
Please donate at http://www.ultidev.com/products/Donate.aspx to help us improve our products.
Ultidev Team
#6 Posted : Thursday, August 2, 2012 11:22:35 AM(UTC)
Ultidev Team

Groups: Administration
Joined: 11/3/2005(UTC)
Posts: 2,253

Thanks: 28 times
Was thanked: 60 time(s) in 59 post(s)
A possible work-around is this: create "app_offline.htm" file in the root of your web app while you are updating files and/or web.config. Remove the file after you are done making changes and ready to restart the app. Having this file will keep UWS in the permanent AppDomain reload loop, but once file is removed, your new application should be able to restart without a problem.

Please let us know if this suggestion has helped.

Best regards,
UltiDev Team.
Please donate at http://www.ultidev.com/products/Donate.aspx to help us improve our products.
Guest
#8 Posted : Thursday, August 2, 2012 11:28:39 AM(UTC)
Groups: Member
Joined: 11/1/2005(UTC)
Posts: 278

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
Ultidev Team
#10 Posted : Thursday, August 2, 2012 12:50:32 PM(UTC)
Ultidev Team

Groups: Administration
Joined: 11/3/2005(UTC)
Posts: 2,253

Thanks: 28 times
Was thanked: 60 time(s) in 59 post(s)
Thank you for the positive feedback, James! We are trying our best to make this product useful.

Best regards,
UltiDev Team.
Please donate at http://www.ultidev.com/products/Donate.aspx to help us improve our products.
Guest
#7 Posted : Wednesday, August 15, 2012 5:08:21 AM(UTC)
Groups: Member
Joined: 11/1/2005(UTC)
Posts: 278

Ultidev Team;3920 wrote:
A possible work-around is this: create "app_offline.htm" file in the root of your web app while you are updating files and/or web.config. Remove the file after you are done making changes and ready to restart the app. Having this file will keep UWS in the permanent AppDomain reload loop, but once file is removed, your new application should be able to restart without a problem.

Please let us know if this suggestion has helped.

Best regards,
UltiDev Team.


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
Ultidev Team
#11 Posted : Wednesday, August 15, 2012 9:41:14 AM(UTC)
Ultidev Team

Groups: Administration
Joined: 11/3/2005(UTC)
Posts: 2,253

Thanks: 28 times
Was thanked: 60 time(s) in 59 post(s)
Hi!

Thank you very much for the positive feedback. We are very happy our web server helps you.

Amount of time required to reload an application depends solely on the size of the application and the speed of the system. Could be anywhere from fractions of a second to more than minute. The whole process with app_offline.htm is done virtually outside of UWS control - it's all ASP.NET runtime. But overall it should take only a few seconds more than having application reloaded due to changes in Bin folder or web.config file.

Best regards,
UltiDev Team.
Please donate at http://www.ultidev.com/products/Donate.aspx to help us improve our products.
Rss Feed  Atom Feed
Users browsing this topic
Guest (5)
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You can vote in polls in this forum.