Maven deploy plugin sometimes fails to deploy correctly

[sunsear]

Plugin name and version

azure-webapp-maven-plugin 0.1.5

Plugin configuration in your pom.xml

                  <plugin>
			<groupId>com.microsoft.azure</groupId>
			<artifactId>azure-webapp-maven-plugin</artifactId>
			<version>0.1.5</version>
			<configuration>
				<authentication>
					<serverId>azure-auth</serverId>
				</authentication>
				<resourceGroup>eotregression</resourceGroup>
				<appName>eotregressionsite</appName>
				<!-- <region> and <pricingTier> are optional. They will be used to create new Web App if the specified Web App doesn't exist -->
				<region>West-Europe</region>
				<pricingTier>S3</pricingTier>

				<!-- Java Runtime Stack-->
				<javaVersion>1.8</javaVersion>
				<javaWebContainer>tomcat 8.5</javaWebContainer>
				<stopAppDuringDeployment>true</stopAppDuringDeployment>

				<!-- FTP deployment -->
				<deploymentType>ftp</deploymentType>
				<!-- Resources to be deployed to your Web App -->
				<resources>
					<resource>
						<!-- Where your artifacts are stored -->
						<directory>${project.basedir}</directory>
						<!-- Relative path to /site/wwwroot/ -->
						<targetPath>webapps</targetPath>
						<includes>
							<include>eot.war</include>
						</includes>
					</resource>
				</resources>
			</configuration>
		</plugin>

Expected behavior

Deployment succeeds always

Actual behavior

In some cases (<- yeah I know, great!) Tomcat cleans the /eot/ exploded folder for everything but a META-INF folder with a manifest file. It then does not unpack the uploaded war into this folder, somehow it thinks that it has already done this. No logging is provided that is at all useful.

Steps to reproduce the problem

[jdneo]

Looks like this is an issue related with the app service. (If the plugin can upload the war onto the cloud).

@sunsear How often do you encounter this problem?

[sunsear]

@jdneo, that is the problem, it’s not easy to predict. I would say once every 5-10 deploys. The thing is, if it’s not stable, then automation becomes an unpredictable beast.

It seems to get better if we set the stopAppDuringDeployment to false. Then however our app slowly but steadily fills the memory and the app server dies with an out of memory error after 15-20 deploys.

This memory issue might be related, there is probably a Driver we use that does not close properly. It could have something to do with the plugin not deploying properly. It’s unclear what the issue is exactly.

[jdneo]

Emm, that might be the problem with the ftp deployment. We are planning to support a new way of the deployment: war deploy. (https://docs.microsoft.com/en-us/azure/app-service/app-service-deploy-zip#deploy-war-file) The ETA might be in April. this kind of deployment will not need the web app to stop during the deployment. Hope that could solve your problem.

[sunsear]

Ah, that way of deployment sounds a lot more like what I’d expect, it feels like it better integrates with tomcat. We will definitely work with that when it becomes available.

The restarting however is a feature that we were looking at in hopes of not having to figure out where exactly our redeploy memory issue is. Doing a restart of the server kills all remaining threads etc.

[jdneo]

😄 I'll inform you in this issue thread when the code is ready.

[jdneo]

Hi @sunsear

We supported war deploy in the feature branch: https://github.com/Microsoft/azure-maven-plugins/tree/cs/wardeploy

Please feel free to have a try if you want. Here is the steps:

# clone the plugin project
git clone git@github.com:Microsoft/azure-maven-plugins.git
cd azure-maven-plugins

# checkout to the feature branch
git checkout cs/wardeploy

# install the snapshot into your local machine
mvn clean install -DskipTests

# Then change the plugin version to 1.1.0-SNAPSHOT in your project pom

Known issues:

• Currently only support Windows Web App.

Here is some description of the pom configuration for wardeploy:

<deploymentType>war</deploymentType>

<!-- Specify the war file location. -->
<!-- By default, the plugin will find the war file according to the final name in the build directory. -->
<!-- E.g. target/${finalName}.war -->
<warFile>C:\\Users\\user\\Desktop\\demo.war</warFile>

<!--Specify the context path for this deployment. -->
<!--By default, the context path will be '/', which is aka the ROOT. -->
<path>/test</path>

[sunsear]

Hi @jdneo,

That sounds Good. Can you say something as to how the plugin then actually does the deployment? Does it use the tomcat manager?

Look forward to hearing from you,

Martin

[jdneo]

@sunsear It use a new deployment endpoint from Kudu. You can find more details in this link: https://github.com/projectkudu/kudu/wiki/Deploying-WAR-files-using-wardeploy

[jdneo]

Closing this issue since it is inactive for a while. @sunsear please feel free to open a new issue if you find the wardeploy still cannot solve your problem. 😄

[sunsear]

Thanks jdneo, we are unfortunately not using wardeploy yet, it hasn’t gotten priority. We used to do 30+ deploys a day, we have reduced that to roughly 5. We were wasting cpu as we really weren’t interested in the others anyway. Those five are rather stable, we only need to restart every 2nd week or so. Thanks for your efforts in this, good to know we have options if we need them.