生产环境中，很久不访问后，附件上传第一次失败

江苏院-吴昊

生产环境中，很久不访问后，附件上传第一次失败。
比如刷新页面才可以恢复正常。
一般是系统很长时间没有访问之后会生产这种情况。

查看biz 和 doc所在服务器的日志都没有明显发现错误。

biz 和 doc 的数据源 都已加上 testOnBorrow=true  validationQuery=' select 1 from DUAL'




具体表现是，上传选择文件后，进度条很快就结束了，除了图标（上传的是图片，未出现预览图）。然后鼠标移上去会报错， 类似 getFormatSize错误，就是没有获取到文件大小。点击保存后，
到文档中心去查看，发现上传的文档大小为0。重新打开业务数据，鼠标移上去报错。

江苏院-吴昊

其中两个字段的值都有有误

jishuang

F12打开浏览器的开发人员调试工具看看network中监控的请求信息是否都成功了

上传后要保存数据才会生成fileID

江苏院-吴昊

jishuang 发表于 2017-11-27 11:48
F12打开浏览器的开发人员调试工具看看network中监控的请求信息是否都成功了

上传后要保存数据才会生成file ...

结贴吧。应该是分开部署的文档服务器 上 doc数据源 链接 长时间未访问导致的。

虽然在加上 validationQuery等配置，但是没有重启成功，所以没有生效。

但是最大的问题是，文档服务器上的各种日志里，竟然没有报错信息，被吞掉了！如果是x5 服务器上数据源的问题，x5 的日志里就会有报错信息。

另外，数据源上 只加上 validationQuery 属性是没有用的，亲测，所以很多帖子说加上后，mysql 8小时连接失效 问题依然 存在。

还需要加上 testOnBorrow = true等属性。

以下资料来自网络，仅供参考：
1. testOnBorrow和testOnReturn在生产环境一般是不开启的，主要是性能考虑。失效连接主要通过testWhileIdle保证，如果获取到了不可用的数据库连接，一般由应用处理异常。

2. 对于常规的数据库连接池，testOnBorrow等配置参数的含义和最佳实践可以参考官方文档。

3. 数据源库连接池的实现原理与dropwizard无关，既然mysql server的wait_timeout等参数被设置为30秒，那么就会主动关闭不活跃的客户端连接，几个test参数设置为true可以通过充分的检测移除不可用连接，并重新创建新的连接，保证应用都获取到健康的连接。

4. my.conf中的wait_timeout参数和interactive_timeout参数默认是28800秒，也就是8小时。一般在生产环境这个数值会被设置为7天甚至30天，目的是保证mysql不会因为流量稀少而主动关闭session. 至于是否会导致大量的sleep连接，这个请在理解以上原理后，自行思考吧。

江苏院-吴昊

tomcat的内置连接池 使用的 dbcp 连接池
建议研究下dbcp的参数配置，来避免数据库连接造成的问题。
http://blog.csdn.net/yp5185423/article/details/8299800/#comments

2017年11月28日 13:55:16
dbcp是默认，是jdbc pool 是可替代的。但是参数都差不多的。

江苏院-吴昊

我是用testOnBorrow = true来解决的，毕竟内网使用，性能要求不高。
实际上，访问量较大的场景不推荐配置这个属性为true。

较好的配置是开启 sweeper线程，如何开启该线程？



具体没试过这样配置会不会出现  获取 失效连接 而导致报错 的问题，大家可以试试。

江苏院-吴昊

结贴啊。。。。。