Grails 4 - Google Cloud Platform deployment keeps restarting - spring

My Grails 4 application, deployed to GCP appears to be trying to start up after being deployed but never comes up properly. Application requests return a 500 response. There are no errors or clues with DEBUG log level output at the root level.
The same application runs fine locally in development mode.
The production configuration is as per the Grails 3 deployment (to GCP) guide except for the adjustments that were necessary to make it work for Grails 4/Java 11.
Most of the bootstrapping appears to carry out as expected;
Spring Security configures successfully
Spring Security REST configures successfully
Spring beans are registered
Connects to Cloud SQL instance
Database schema is created (by Liquibase)
Plugins are loaded successfully
Then it gets to the following familiar lines of output logging;
INFO --- [main] o.s.b.w.embedded.tomcat.TomcatWebServer : Tomcat initialized with port(s): 8080 (http)
INFO --- [main] o.a.coyote.http11.Http11NioProtocol : Initializing ProtocolHandler ["http-nio-8080"]
INFO --- [main] o.apache.catalina.core.StandardService : Starting service [Tomcat]
INFO --- [main] org.apache.catalina.core.StandardEngine : Starting Servlet engine: [Apache Tomcat/9.0.17]
and restarts..
while normally, the next phase of bootstrapping (happens locally) would be;
[restartedMain] o.a.c.c.C.[Tomcat].[localhost].[/] : Initializing Spring embedded WebApplicationContext
[restartedMain] o.s.web.context.ContextLoader : Root WebApplicationContext: initialization completed in 42018 ms
Probably a long shot question but any level of clues or suggestions would be much appreciated.
I've run out of doors to open. :-(

You could try to update Tomcat version just in case.
But looking at Grails documentation:
https://docs.grails.org/latest/guide/upgrading.html
There's some configuration made when you upgrade to Grails 4 from
Grails 3.3.x to prevents the server from restarting when views or
message bundles are changed.
Either modifying a gsp in Grails 4 M2 cause the application to restart.
https://github.com/grails/grails-core/issues/11284

Related

Starting springboot application from IntelliJ community edition

How can we start a spring boot application in IntelliJ community edition. I don't see an embedded tomcat Included here. When I start the application from SpringBootApplication annotated class, getting the below messages only in the logger
2021-06-23 20:02:45.933 INFO 1086 --- [ main] r.e.r.RestapplicationApplication : Starting RestapplicationApplication using Java 11.0.11 on Antonys-MBP.home with PID 1086 (/Users/robin/Documents/work/workspace/restapplication/target/classes started by robin in /Users/robin/Documents/work/workspace/restapplication)
2021-06-23 20:02:45.938 INFO 1086 --- [ main] r.e.r.RestapplicationApplication : No active profile set, falling back to default profiles: default
2021-06-23 20:02:48.342 INFO 1086 --- [ main] r.e.r.RestapplicationApplication : Started RestapplicationApplication in 3.621 seconds (JVM running for 4.888)
Please help on how can I start the application in tomcat and test in Community Editon of IntelliJ
r.e.r.RestapplicationApplication : Started RestapplicationApplication
in 3.621 seconds (JVM running for 4.888)
The above line tells you that the embedded tomcat has already started at default port 8080 ( unless you have overridden port in configuration). You can try hitting the application on the port.

ContextLoader - Root WebApplicationContext initialized 3 times on ubuntu tomcat

Dears,
I have a jersey - spring api deployed on apache tomcat 9.0.46. (Jersey to handle restful services JAX-RS and Spring to handle all my beans{controllers, DAO, SessionFactory, JPA etc...}).
Everything works fine on tomcat 9 on windows...
When deploying the exact same war in ubuntu tomcat 9.0.46, the ContextLoader is getting triggered 3 times and I have all my singletons instantiated 3 times. I'm deploying the api on tomcat ports 80 and 443 (https - godady certificate).
once I start tomcat the war is deployed and ports 80 and 443 get started (netstat -tulnp | grep java) and I see in log all singletons instantiated. (pool-2) Applicationcontext class my custom spring #Configuration class and it is getting triggered and DB is accessed without any issues
2021-06-09 14:41:52,128 1104 [main] INFO o.s.web.context.ContextLoader - Root WebApplicationContext initialized in 905 ms
2021-06-09 14:41:53,124 2100 [pool-2-thread-1] INFO skd.app.core.ApplicationContext - TASK::cleanExpiredStatuses
then the server takes few minutes (around 10 minutes 14:41 above then 14:51 below) and when port 8005 is started I see again the ContextLoader is triggered again 2 times.
09-Jun-2021 14:51:36.196 WARNING [main] org.apache.catalina.util.SessionIdGeneratorBase.createSecureRandom Creation of SecureRandom instance for session ID generation using [SHA1PRNG] took [584,064] milliseconds.
09-Jun-2021 14:51:36.592 INFO [main] org.glassfish.jersey.server.ApplicationHandler.initialize Initiating Jersey application, version Jersey: 2.6 2014-02-18 21:52:53...
09-Jun-2021 14:51:37.042 INFO [main] org.apache.catalina.startup.HostConfig.deployWAR Deployment of web application archive [/opt/apache-tomcat-9.0.46/webapps/skd-service.war] has finished in [588,185] ms
2021-06-09 14:51:39,388 696 [main] INFO o.s.web.context.ContextLoader - Root WebApplicationContext initialized in 581 ms
09-Jun-2021 14:51:39.632 INFO [main] org.glassfish.jersey.server.ApplicationHandler.initialize Initiating Jersey application, version Jersey: 2.6 2014-02-18 21:52:53...
09-Jun-2021 14:51:40.013 INFO [main] org.apache.catalina.startup.HostConfig.deployWAR Deploying web application archive [/opt/apache-tomcat-9.0.46/webapps/skd-service.war]
and again for the 3rd time:
2021-06-09 14:51:41,989 744 [main] INFO o.s.web.context.ContextLoader - Root WebApplicationContext initialized in 605 ms
09-Jun-2021 14:51:42.232 INFO [main] org.glassfish.jersey.server.ApplicationHandler.initialize Initiating Jersey application, version Jersey: 2.6 2014-02-18 21:52:53...
09-Jun-2021 14:51:42.602 INFO [main] org.apache.catalina.startup.HostConfig.deployWAR Deployment of web application archive [/opt/apache-tomcat-9.0.46/webapps/skd-service.war] has finished in [2,590] ms
Everything is working fine in windows, only when deploying to ubuntu tomcat, I'm getting this.
Does anyone have a clue why this difference in tomcat behaviour between windows and ubuntu for the same exact WAR file?
I have managed to figure out the problem. The issue was related to tomcat configuration in /conf/server.xml. Multiple Hosts will trigger the context loader to be triggered for each. I was keeping the default appBase to webapps for all host thus triggering the ContextLoader of each my war for each host. Another reason the ContextLoader will triggered multiple times as well is defining the option inside unless you need to load something external to your war.
I recommend reading specs:
https://tomcat.apache.org/tomcat-4.1-doc/config/host.html

Why App Engine can't connect to Cloud SQL with my Spring Boot app?

I'm trying to connect my App Engine application (in Java Spring Boot) with a Cloud SQL database. Deployment is working and app start but block on Connection to Cloud SQL :
main] c.g.cloud.sql.core.CoreSocketFactory : First Cloud SQL connection, generating RSA key pair.
main] c.g.cloud.sql.core.CoreSocketFactory : Connecting to Cloud SQL instance [test-api:europe-west1:test-db] via SSL socket.
// Nothing happens after that !
What I do ?
1) I create a user on my database with a username and a password (for example postgres and postgres).
2) I add this dependency to my project
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-gcp-starter</artifactId>
<version>1.1.2.RELEASE</version>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-gcp-starter-sql-postgresql</artifactId>
<version>1.1.2.RELEASE</version>
</dependency>
3) I update application.properties with
# Gcp configuration
spring.cloud.gcp.sql.database-name=test
spring.cloud.gcp.sql.instance-connection-name=test-api:europe-west1:test-db
#Jdbc connection
spring.datasource.username=postgres
spring.datasource.password=postgres
spring.datasource.url=jdbc:postgresql://google/test?cloudSqlInstance=test-api:europe-west1:test-db&socketFactory=com.google.cloud.sql.postgres.SocketFactory&useSSL=false&user=postgres&password=postgres
What is the problem ?
The problem is that nothing happens after Connecting to Cloud SQL instance log. (see before)
In the log of launch I can see that informations :
main] o.s.b.w.embedded.tomcat.TomcatWebServer : Tomcat initialized with port(s): 8080 (http)
main] o.apache.catalina.core.StandardService : Starting service [Tomcat]
main] org.apache.catalina.core.StandardEngine : Starting Servlet engine: [Apache Tomcat/9.0.19]
main] o.a.c.c.C.[Tomcat].[localhost].[/] : Initializing Spring embedded WebApplicationContext
main] o.s.web.context.ContextLoader : Root WebApplicationContext: initialization completed in 11980 ms
main] o.s.c.g.a.s.GcpCloudSqlAutoConfiguration : Default POSTGRESQL JdbcUrl provider. Connecting to jdbc:postgresql://google/test?socketFactory=com.google.cloud.sql.postgres.SocketFactory&socketFactoryArg=test-api:europe-west1:test-db&useSSL=false with driver org.postgresql.Driver
main] o.s.c.g.a.s.GcpCloudSqlAutoConfiguration : spring.datasource.url is specified. Not using generated Cloud SQL configuration
main] com.zaxxer.hikari.HikariDataSource : HikariPool-1 - Starting...
main] c.g.cloud.sql.core.CoreSocketFactory : First Cloud SQL connection, generating RSA key pair.
main] c.g.cloud.sql.core.CoreSocketFactory : Connecting to Cloud SQL instance [test-api:europe-west1:test-db] via SSL socket.
Other curious point is that I specify &useSSL=false but app is connecting via SSL socket according to log.
This sounds very similar to what was happening in github/cloud-sql-jdbc-socket-factory #148. The issue was a dependency conflict, where an outdated version of guava as causing problems. Can you check what version of guava you have specified?
Also, no need to be concerned about using &useSSL=false - the JDBC SF always uses SSL, so this is intentional.

Spring-Boot Server is not running, hangs after Initializing Spring FrameworkServlet 'dispatcherServlet

After running the spring-boot App, I'm getting the below logs:
Using below:
Kubernetes
Bit-Bucket Pipeline
MySQL and Oracle
Consul
Running Debug Mode
2019-07-17 10:33:03 [0] [main] INFO c.n.c.sources.URLConfigurationSource - To enable URLs as dynamic configuration sources, define System property archaius.configurationSource.additionalUrls or make config.properties available on classpath.
2019-07-17 10:33:11 [0] [http-nio-9080-exec-2] INFO o.a.c.c.C.[Tomcat].[localhost].[/] - Initializing Spring FrameworkServlet 'dispatcherServlet'

Spring / IntelliJ doesn't clear session data on stop

I ran in a weird situation I never had before.
I've got a spring boot application running on intelliJ on ubuntu 18.
My spring boot application runs in a dev environment connected to a h2 in memory database. I have a session based login with spring security.
The weird thing is if after I stopped and restarted the application I am still logged in. And even if I completely restart IntelliJ the session is not cleared. Even the database keeps its state and is not getting dropped.
Only if I restart the whole system everything will be cleared.
Inside my application.properties there are no special properties set.
Everything's on default.
If I stop the application the following console output comes up:
2018-12-22 11:11:19.385 INFO 10000 --- [ Thread-35] ConfigServletWebServerApplicationContext : Closing org.springframework.boot.web.servlet.context.AnnotationConfigServletWebServerApplicationContext#73abcbfa: startup date [Sat Dec 22 11:11:00 CET 2018]; parent: org.springframework.context.annotation.AnnotationConfigApplicationContext#12e6f48a
2018-12-22 11:11:19.391 INFO 10000 --- [ Thread-35] o.s.j.e.a.AnnotationMBeanExporter : Unregistering JMX-exposed beans on shutdown
2018-12-22 11:11:19.391 INFO 10000 --- [ Thread-35] o.s.j.e.a.AnnotationMBeanExporter : Unregistering JMX-exposed beans
2018-12-22 11:11:19.395 INFO 10000 --- [ Thread-35] j.LocalContainerEntityManagerFactoryBean : Closing JPA EntityManagerFactory for persistence unit 'default'
2018-12-22 11:11:19.395 INFO 10000 --- [ Thread-35] .SchemaDropperImpl$DelayedDropActionImpl : HHH000477: Starting delayed drop of schema as part of SessionFactory shut-down'
2018-12-22 11:11:19.415 WARN 10000 --- [ Thread-35] o.s.b.f.support.DisposableBeanAdapter : Invocation of destroy method failed on bean with name 'inMemoryDatabaseShutdownExecutor': org.h2.jdbc.JdbcSQLException:Database is already closed (to disable automatic closing at VM shutdown, add ";DB_CLOSE_ON_EXIT=FALSE" to the db URL) [90121-197]
2018-12-22 11:11:19.417 INFO 10000 --- [ Thread-35] com.zaxxer.hikari.HikariDataSource : HikariPool-1 - Shutdown initiated...
2018-12-22 11:11:19.419 INFO 10000 --- [ Thread-35] com.zaxxer.hikari.HikariDataSource : HikariPool-1 - Shutdown completed.
Process finished with exit code 130 (interrupted by signal 2: SIGINT)
https://github.com/spring-projects/spring-boot/wiki/spring-boot-1.3.0-m3-release-notes
Update Tomcat, Jetty and Undertow to serialize session data when the
application is stopped and load it again when the application
restarts. Persistent session are opt-in; either by setting
persistentSession on the ConfigurableEmbeddedServletContainer or by
using the property server.session.persistent=true (Persistent sessions
are enabled by default with Devtools).
In spring boot 2, the property is:
server.servlet.session.persistent=false # Whether to persist session data between restarts.
I suppose you are talking about web login via browser (or REST-client). Also I suppose you're using default web security settings.
Then your login request creates a cookie with session id which is returned to browser and is being used in next requests until you close browser.

Resources