1

I love the idea of swapping slots in Azure, but it doesn't seem to be working correctly.

I have a client app that is uploading files to the server, each as a separate request. When I attempt a server swap it will hang on one of the file uploads and that request will fail. Likewise, if I refresh the production slot's web page it will hang. This only happens for like 30 seconds and then everything is good, but it's enough to interrupt requests.

I read somewhere that sticky slot settings can cause this, so I disabled those but it still happens.

Any ideas? This is a nodeJs web app.

Thank you, Sam

Sam
  • 845
  • 7
  • 20

1 Answers1

1

As the different slots can be treated as different applications. If your request is pending on the production slot when the web app is swapping, it should fail. As we can find the reason:

Finally, the site that used to be Production and is now Staging also needs to get some settings apply, causing it to restart. Again, this is fine since it happens in the staging site.

You can try to use the try catch to get the exception, log the failed file, and try to upload this file again when your site swapping is completed.

Please refer to https://github.com/projectkudu/kudu/wiki/Understanding-site-swaps and http://ruslany.net/2015/09/how-to-warm-up-azure-web-app-during-deployment-slots-swap/ for more info about site swaps.

Gary Liu
  • 13,758
  • 1
  • 17
  • 32
  • Hi. I have a query, but i can't ask it as a question on SO. Can you tell me why same Azure vm costs different for different regions. What, if any can be the disadvantage of running in a region(like south Central us) which has lower price for the vm of my interest(D1v2)? – It's a trap Aug 19 '16 at 05:44
  • As I am not familiar with the business layer, but I think it could caused by the costs on building and maintaining the data centers, services in different regions are different. And it is the common case that a same production has different price in different counties. And for the price of VM, you can refer to https://azure.microsoft.com/en-us/pricing/details/virtual-machines/#Windows for details. – Gary Liu Aug 19 '16 at 06:47
  • Thanks. That means in terms of performance and network bandwidth etc, they are identical. Isn't it? – It's a trap Aug 19 '16 at 07:56
  • 1
    It makes sense to me. It would seem to me that the requests sent to production (which now becomes staging) should be allowed to complete before restarting, but that's just me. I'll just have to retry the request as you said. It's still cool that there's no "warm up" time. :) – Sam Aug 20 '16 at 01:41
  • Sorry if these are dumb questions, I'd really like to know if you have the time: Would there be an exception to log? Isn't the production app terminated when it's restarted (after being switched to staging)? So how would that trigger an exception? And therefore those requests are just dropped in the middle of processing? Like Sam said, are the requests allowed to complete? I know StackOverflow, during their deployment process, allow a few seconds for requests to complete so nothing is dropped. Are slots really swapped instantly or are there a few seconds of leeway? Thanks – nmit026 Nov 30 '16 at 22:07