Production mode required change from localhost to explicit IP in database url property

pclark

Running on Windows Server 2019 with MySQL 8, FusionAuth v1.21.0. Not sure if this is a bug or just related to my own configuration.
Changed FusionAuth from Development mode to Production mode, and then couldn't connect to the database.
Database connection url property was:

jdbc:mysql://localhost:3306/fusionauth?serverTimezone=UTC&useSSL=false&allowPublicKeyRetrieval=true

After digging a little on the following errors, I worked around the issue by changing the database connection url property to the machine's explicit IP, and was able to connect.

jdbc:mysql://xxx.xxx.xxx.xxx:3306/fusionauth?serverTimezone=UTC&useSSL=false&allowPublicKeyRetrieval=true

For reference:
Tomcat startup showed these errors:

SEVERE: Exception sending context initialized event to listener instance of class [io.fusionauth.app.primeframework.FusionAuthAppPrimeServletContextListener]
org.primeframework.mvc.PrimeException
        at org.primeframework.mvc.guice.GuiceBootstrap.initialize(GuiceBootstrap.java:77)
        at org.primeframework.mvc.servlet.PrimeServletContextListener.contextInitialized(PrimeServletContextListener.java:61)
        at com.inversoft.maintenance.servlet.MaintenanceModePrimeServletContextListener.contextInitialized(MaintenanceModePrimeServletContextListener.java:45)
        at io.fusionauth.app.primeframework.FusionAuthAppPrimeServletContextListener.contextInitialized(FusionAuthAppPrimeServletContextListener.java:26)
        at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4689)
        at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5155)
        at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
        at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1412)
        at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1402)
        at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
        at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
        at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
        at java.base/java.lang.Thread.run(Thread.java:832)

FusionAuth log showed these errors:

2020-11-24 11:11:05.863 AM ERROR com.zaxxer.hikari.pool.HikariPool - HikariPool-1 - Exception during pool initialization.
com.mysql.cj.jdbc.exceptions.CommunicationsException: Communications link failure
The last packet sent successfully to the server was 0 milliseconds ago. The driver has not received any packets from the server.
	at com.mysql.cj.jdbc.exceptions.SQLError.createCommunicationsException(SQLError.java:174)

        ...several hundred lines of stack...

Unable to start the server. Here's why: 
[Error in custom provider, com.zaxxer.hikari.pool.HikariPool$PoolInitializationException: Failed to initialize pool: Communications link failure

The last packet sent successfully to the server was 0 milliseconds ago. The driver has not received any packets from the server.] 
	-> [class com.zaxxer.hikari.pool.HikariPool$PoolInitializationException] Failed to initialize pool: Communications link failure

pclark

Two updates:

The workaround to use the explicit IP instead of localhost only works sometimes, indicating that there continues to be some kind of timing/timeout issue in Production mode, but not in Development mode.
Adding a second processor seems to have actually fixed the issue.

dan

Hmmm. Do you have precise replication steps? This may be a subtle bug that only shows up in your environment and if you have reliable replication steps we'd love to have you file a bug: https://github.com/fusionauth/fusionauth-issues/issues

This SO answer looks interesting too; appears there's a wide variety of reasons why you might see this error.

pclark

Thanks for your response. The only thing I did was try to set up as close to a "standard" Windows installation as possible, then changed FusionAuth to Production mode. Will say that the DB (MySQL 8.0.22) is on the same machine as FusionAuth, so the fact that additional resources solved a timing issue wasn't surprising. I'm no MySQL expert, so very well could have been solved by a setup/configuration issue there.

dan

@pclark okay, thanks. Sometimes there are issues if FusionAuth is underprovisioned; I wonder if that is something you ran into.

I'm glad you found a workaround. If this pops up again, we can try to recreate.