Azure App Service
Azure App Service is a service used to create and deploy scalable, mission-critical web apps.
7,663 questions
deploy java app to linux container - determine when app is "ready"
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(265.6, 33%, 35%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ESB%3C/text%3E%3C/svg%3E)
Schenz, Brandon
11
Reputation points
53665-webapp-blue.logWhy does "Waiting for response to warmup request for container" take multiple minutes?
How can I make it run faster in a CI/CD type of use case?
I'm using the Azure/webapps-deploy@v2 github action to deploy a new jar file (with java agent for Application Insights), but old version keeps running for a considerable amount of time (multiple minutes) with that warmup message, then change is detected and app reload seems to happen with the warmup message for several more minutes.
I guess I really don't mind it taking so long, but need to know how to monitor for the new version to be running so that I can then run tests of the new deployment in the slot, then switch slots when those tests all run.
{count} votes
-
Schenz, Brandon 11 Reputation points
2021-01-05T19:40:46.187+00:00 Also, after I get this one buttoned up, I'm not convinced that slot swapping is not al;so triggering this same type of behavior instead of just moving warmed/ready slots to production.
-
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(153.6, 92%, 24%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EA%3C/text%3E%3C/svg%3E)
ajkuma 25,781 Reputation points Microsoft Employee2021-01-06T11:27:15.447+00:00 @Schenz, Brandon , Thanks for posting this great question.
Just to confirm, when you say, ‘how to monitor for the new version to be running so that I can then run tests of the new deployment in the slot’, are you looking at detecting the deployment has reflected across the slot?
To get to the root of the issue, we can review Application logs, GitHub Actions and docker logs. I’ll follow-up with you privately to fetch these details.
Just to highlight on container start-up process - When your site starts, we run your Docker image and create a Docker container. Your app runs inside of that container, and the file system contains only what is in the Docker image. If your Docker image doesn't install a particular component, it won't be there when your container starts. You can provide an optional startup command that will be run as part of container startup. From “Startup Command” under WebApp “General settings”. E.g. java -jar /home/site/wwwroot/app.jar --server.port=80
-
ajkuma 25,781 Reputation points Microsoft Employee
2021-01-06T11:30:48.083+00:00 @Schenz, Brandon , Adding more:
Some apps might require custom warm-up actions before the swap. The applicationInitialization configuration element in web.config lets you specify custom initialization actions. The swap operation waits for this custom warm-up to finish before swapping with the target slot.
WEBSITE_SWAP_WARMUP_PING_PATH: The path to ping to warm up your site. Add this app setting by specifying a custom path that begins with a slash as the value. An example is /statuscheck. The default value is /.WEBSITE_SWAP_WARMUP_PING_STATUSES: Valid HTTP response codes for the warm-up operation. Add this app setting with a comma-separated list of HTTP codes. An example is 200,202 . If the returned status code isn't in the list, the warmup and swap operations are stopped. By default, all response codes are valid. -
ajkuma 25,781 Reputation points Microsoft Employee
2021-01-06T11:46:44.587+00:00 @Schenz, Brandon , This is what happens when you swap a source slot (let's call it 'Staging') into a target slot (Production).
1.First, the Staging site needs to go through some setting changes for App Setting and Connection Strings that are marked as 'slot'. This causes the Staging site to restart, which is fine.
2.Next, the Staging site gets warmed up, by having a request sent to its root path (i.e. '/'), and waiting for it to complete.
3.Now that the Staging site is warm, it gets swapped into Production. There is no down time, since it goes straight from one warm site to another one.
4.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.Some config elements are slot specific (stay) and others not slot specific (across a swap).
Sign in to comment
Sign in to answer