Grails 3.3.3 war部署在具有关闭jdbc连接的tomcat 8.5问题上

Question

当我在容器中运行war文件时，它显示为在服务器端丢弃的连接(默认空闲超时为8h)导致异常(根本原因:连接已关闭/服务器的最后一个成功包是在0ms之前或表示>8h的值之前发送的。在重新启动容器之前，这些异常是不可恢复的。

问题1)将jdbc-tomcat池作为依赖项添加到build.grade运行时"org.apache.tomcat:tomcat-jdbc“时，不会尝试重新连接到”主“dataSource之外的”断开的“dataSource(在dataSources下面)。不管这些属性是什么: 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.  

因此，我从gradle中删除了tomcat-jdbc，并将其放在每个url ?autoReconnect=true之后。尽管如此，一些属性仍然会产生影响。属性: initialSize: 2#连接池大小maxActive: 20 minIdle: 2 maxIdle: 20以上值导致在闭包内使用20次连接(顺序，而不是并行)进行20次调用后，第21次调用失败。在整个过程中，观察mariadb端的打开连接时，有零个或一个并发conns。在删除属性后，它起作用了。为什么当conn池未加载时，此值会影响？

Tomcat自带了自己的tomcat-jdbc jar，这可能会有所不同。是否需要在build.grade中将类型更改为"provided“，就像tomcat本身一样？

问题2)是，web发现，也就是在这个论坛上，但grails文档本身也指向https://grails.org/deployment。doc提到了部署到容器时的注意事项，当我注册时，我没有收到确认电子邮件，页面会转发到https://grails.org/unauthorized。在我看来，注册似乎被打破了。是否有对应的电子邮件联系人-找不到任何联系人。

我只是不敢相信我花了这么长时间才在web容器中拥有一个普通的池。在旧的容器版本中，fin也可以工作

Answer 1

找到了。这是由于3个问题：

必须提供tomcat-jdbc的

1. gradle依赖类型，并且不进行编译以避免冲突( tomcat "dataSources:")
2. if application.yml的库部分(和application.yml的本地文件重载内容))属性下的"dataSource:“对于池没有被其他数据源继承(定义在下面的anchor”dataSources：“)
3. if中的一个操作没有在removeAbandonedTimeout: 60 (秒)内完成)，连接被拉回，这触发了连接失败异常。增加了价值。不幸的是，它是不可见的，因为removeAdbandoned被设置为true，但logAbandoned并非如此。