1

I'm trying to deploy a locally build Spring Boot application to Azure App Service. Note I'm new to using Azure.

The App Service I created using the Azure Portal has the following characteristics:

  • Stack: Java SE (JRE 8)

This should make running the application as jar possible.

I've also added the following application settings (env vars):

  • JAVA_OPTS: -Dserver.port=80
  • SPRING_PROFILES_ACTIVE: prod

This should set the correct server port, assuming port 80 is the correct one I should use. I read this other posts. The second application setting will make sure the prod profile inside the application is used.

I connected to App Service using FTP and removed the default.jar and uploaded my own app.jar and then restarted the App Service.

I get a notification the app was restarted but it doesn't seem to work. I cannot access the application but I'm also not able to find log files. Trying the Log Stream in the Azure Portal only gives info regarding Starting container for site and docker related logs, but not the logs of my application.

I wonder where I should look next to troubleshoot.

Note, I'm using the FTP deployment option as my application is build with Gradle and Azure only seems to have a Maven plugin for deploying apps.

UPDATE

I've added a web.config using FTP containing:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <handlers>
            <add name="httpPlatformHandler" path="*" verb="*" modules="httpPlatformHandler" resourceType="Unspecified" />
        </handlers>
        <httpPlatform processPath="%JAVA_HOME%\bin\java.exe"
            arguments="-Djava.net.preferIPv4Stack=true -Dserver.port=%HTTP_PLATFORM_PORT% -jar &quot;%HOME%\site\wwwroot\app.jar&quot;">
        </httpPlatform>
    </system.webServer>
</configuration>

I restarted the App Service but still the same. I also get no errors (or at least I don't know where to look).

UPDATE 2

Via "Diagnose and solve problems" in de Azure Portal I was able to view application logs.

They show the application started successfully, but then it gives a:

2019-01-25T12:53:31.730996889Z #
2019-01-25T12:53:31.731125589Z # A fatal error has been detected by the Java Runtime Environment:
2019-01-25T12:53:31.731207089Z #
2019-01-25T12:53:31.737259893Z #  SIGSEGV (0xb) at pc=0x000000000000b32e, pid=197, tid=0x00007fab3d393ae8
2019-01-25T12:53:31.740444095Z #
2019-01-25T12:53:31.740455395Z # JRE version: OpenJDK Runtime Environment (8.0_192-b01) (build 1.8.0_192-b01)
2019-01-25T12:53:31.740459895Z # Java VM: OpenJDK 64-Bit Server VM (25.192-b01 mixed mode linux-amd64 compressed oops)
2019-01-25T12:53:31.740463995Z # Problematic frame:
2019-01-25T12:53:31.740467795Z # C  0x000000000000b32e
2019-01-25T12:53:31.740471495Z #
2019-01-25T12:53:31.740475195Z # Core dump written. Default location: //core or core.197
2019-01-25T12:53:31.740479095Z #
2019-01-25T12:53:31.770424313Z # An error report file with more information is saved as:
2019-01-25T12:53:31.778837718Z # //hs_err_pid197.log
2019-01-25T12:53:31.827292848Z #
2019-01-25T12:53:31.827404948Z # If you would like to submit a bug report, please visit:
2019-01-25T12:53:31.827534548Z #   http://www.azulsystems.com/support/
2019-01-25T12:53:31.827635448Z #
2019-01-25T12:53:32.357760775Z /bin/init_container.sh: line 123:   197 Segmentation fault      (core dumped) java $JAVA_OPTS -jar "$JAR_PATH"
Docker logs from instance: RD0003FF30DE7C

Note the same apps runs successfully on Heroku for months.

Marcel Overdijk
  • 11,041
  • 17
  • 71
  • 110
  • Did you add the web.config file? – George Chen Jan 25 '19 at 07:36
  • @GeorgeChen No, is this also needed when copying just a jar using ftp? Do you now how the web.config should look in that case? Should it be dropped in same location as jar? – Marcel Overdijk Jan 25 '19 at 11:15
  • I've added a web.config as described on https://github.com/uglide/azure-content/blob/master/articles/app-service-web/web-sites-java-custom-upload.md but without success. – Marcel Overdijk Jan 25 '19 at 12:51
  • Firstly you should make sure your jar file is runnable , then your logs show "hs_err_pid197.log" is stored , maybe you could check it. And about detailed steps to deploy spring boot you could refer to this answer.https://stackoverflow.com/a/39444340/10383250 – George Chen Jan 28 '19 at 05:36
  • Yes the jar file was runnable; it was a standard Spring Boot app. I will post an answer to my own query; there were various things going on. – Marcel Overdijk Jan 28 '19 at 15:00

2 Answers2

1

There were a couple of things going on. After adding the mentioned web.config the app was deploying.

The A fatal error has been detected by the Java Runtime Environment was due to using Ehcache using a combination of in memory and disk store.

After removing Ehcache from the application the app was still not working and based on the logs I found out that the app was not starting within 230s. After updating the application setting WEBSITES_CONTAINER_START_TIME_LIMIT to 1800 it worked.

Why the app is taking so long to startup I don't know. Looking at the logs there is no big time spent in some area; it's just gradually slow. The apps startups locally in 8s and on Heroku in 20s.

Marcel Overdijk
  • 11,041
  • 17
  • 71
  • 110
1

App Service has support for running java on Windows and Linux. The Web.config artifact only works when running on Windows and for your case since you are using App Service Linux, this artifact won't be used at all.

We also have some settings that can be tuned such as WEBSITES_CONTAINER_START_TIME_LIMIT but there are others like WEBSITES_PORT to configure the port your container will use. Please review the FAQ: https://learn.microsoft.com/en-us/azure/app-service/containers/app-service-linux-faq

Also please review the Java developer guide for App Service: https://learn.microsoft.com/en-us/azure/app-service/containers/app-service-linux-java

Thanks,

Joaquín

Joaquín Vano
  • 414
  • 1
  • 3
  • 5
  • Hi Joaquin, yes I read those. But when you are new on the platform it's quite difficult to find out why the jar is not running. – Marcel Overdijk Jan 30 '19 at 07:29
  • 1
    Also the fact that the app is running without problems locally and immediately on Heroku without changes gave some startup problems running it on Azure. Like when using Ehcache getting the fatal error; again on Heroku it worked right away. Anyway the app is now running and thx for your feedback. – Marcel Overdijk Jan 30 '19 at 07:32
  • 1
    I'm now utterly surprised how difficult it is to use Let's Encrypt on Azure for custom domains. And that for one of the leading PaaS providers... On Netlify, Heroku etc, it's just the click of a button to enable such a feature. Azure could do more here to strive for a more secure web using https everywhere. – Marcel Overdijk Jan 30 '19 at 07:34