0

When I run the war file in the container, it appears as the connection dropped on the server side (default idle timeout there is 8h) leads to exceptions (root cause: connection already closed / the last successful package to the server was sent either 0ms ago or a value representing >8h. those exceptions are not recoverable until restarting the container.

Problem 1) when adding the jdbc-tomcat pool as dependency in build.grade runtime "org.apache.tomcat:tomcat-jdbc" re-connections to disconnected "other than the main" dataSource (below dataSources) are not attempted. regardless of those properties: dataSource: pooled: true jmxExport: true driverClassName: com.mysql.jdbc.Driver
dialect: org.hibernate.dialect.MySQL5InnoDBDialect properties: initialSize: 2 # connection pool size maxActive: 10 minIdle: 0 maxIdle: 10 removeAbandonedTimeout: 120 # free connection used by quartz job removeAbandoned: true validationQuery: SELECT 1 testOnBorrow: true maxWait: 10000 maxAge: 600000 timeBetweenEvictionRunsMillis: 5000 minEvictableIdleTimeMillis: 60000 validationQueryTimeout: 3 validationInterval: 15000 testWhileIdle: true testOnReturn: false jdbcInterceptors: ConnectionState defaultTransactionIsolation: java.sql.Connection.TRANSACTION_READ_COMMITTED "other" DS are supported fully in terms of pooling in the grails/tomcat combination.

So, I removed tomcat-jdbc from gradle and put after every url ?autoReconnect=true. Still, some of the properties influence. properties: initialSize: 2 # connection pool size maxActive: 20 minIdle: 2 maxIdle: 20 the values above caused, after 20 calls within a closure using 20 times a connection (sequentially, not in parallel) the 21st one to fail. at the whole time, watching the open connections on mariadb side there was zero or one concurrent conns. after removing the properties it worked. why do this values influence when conn pool is not loaded?

Tomcat comes with its own tomcat-jdbc jar, which could make a difference. is it required to change type to "provided" in build.grade, just like for tomcat itself?

Problem 2) is, web findings, i.e. also in this forum, but also grails documentation itself point to https://grails.org/deployment. doc mentions caveats when deploying to containers being documented there...but when I register, I get no confirmation email and the page forwards to https://grails.org/unauthorized. it appears to me as if the registration is broken. Is there an email contact for that - couldn't find any.

I just can't believe that this takes me so long to have a plain pool in a web container. Things worked fin also in the old container version

einsatzmaenner
  • 21
  • 2

1 Answers1

0

Found it. it was due to 3 problems:

  1. gradle dependency type for tomcat-jdbc must be provided and not compile to avoid conflict (lib part of tomcat installation)

  2. in application.yml (and local file overloading content of application.yml) properties below "dataSource:" for pooling were not in inherited by other datasources (defined below anchor "dataSources:")

  3. if an action is not completed within removeAbandonedTimeout: 60 (seconds), the connections are ripped back which triggered the connection failure exceptions. increased the value. unfortunately it was invisible since removeAdbandoned was set to true, but not so logAbandoned.

einsatzmaenner
  • 21
  • 2