org.springframework.web.util.NestedServletException: Request processing failed; nested exception is org.springframework.dao.RecoverableDataAccessException:
; SQL []; The last packet successfully received from the server was 163,547,737 milliseconds ago. The last packet sent successfully to the server was 163,547,738 milliseconds ago. is longer than the server configured value of 'wait_timeout'. You should consider either expiring and/or testing connection validity before use in your application, increasing the server configured values for client timeouts, or using the Connector/J connection property 'autoReconnect=true' to avoid this problem.; nested exception is com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: The last packet successfully received from the server was 163,547,737 milliseconds ago. The last packet sent successfully to the server was 163,547,738 milliseconds ago. is longer than the server configured value of 'wait_timeout'. You should consider either expiring and/or testing connection validity before use in your application, increasing the server configured values for client timeouts, or using the Connector/J connection property 'autoReconnect=true' to avoid this problem.
org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:979)
org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:858)
javax.servlet.http.HttpServlet.service(HttpServlet.java:635)
org.springframework.web.servlet.FrameworkServlet.service(FrameworkServlet.java:843)
javax.servlet.http.HttpServlet.service(HttpServlet.java:742)
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
Root Cause
org.springframework.dao.RecoverableDataAccessException:
; SQL []; The last packet successfully received from the server was 163,547,737 milliseconds ago. The last packet sent successfully to the server was 163,547,738 milliseconds ago. is longer than the server configured value of 'wait_timeout'. You should consider either expiring and/or testing connection validity before use in your application, increasing the server configured values for client timeouts, or using the Connector/J connection property 'autoReconnect=true' to avoid this problem.; nested exception is com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: The last packet successfully received from the server was 163,547,737 milliseconds ago. The last packet sent successfully to the server was 163,547,738 milliseconds ago. is longer than the server configured value of 'wait_timeout'. You should consider either expiring and/or testing connection validity before use in your application, increasing the server configured values for client timeouts, or using the Connector/J connection property 'autoReconnect=true' to avoid this problem.
org.springframework.jdbc.support.SQLExceptionSubclassTranslator.doTranslate(SQLExceptionSubclassTranslator.java:98)
org.springframework.jdbc.support.AbstractFallbackSQLExceptionTranslator.translate(AbstractFallbackSQLExceptionTranslator.java:73)
org.springframework.jdbc.support.AbstractFallbackSQLExceptionTranslator.translate(AbstractFallbackSQLExceptionTranslator.java:81)
org.mybatis.spring.MyBatisExceptionTranslator.translateExceptionIfPossible(MyBatisExceptionTranslator.java:74)
org.mybatis.spring.SqlSessionTemplate$SqlSessionInterceptor.invoke(SqlSessionTemplate.java:399)
com.sun.proxy.$Proxy11.selectOne(Unknown Source)
org.mybatis.spring.SqlSessionTemplate.selectOne(SqlSessionTemplate.java:165)
org.apache.ibatis.binding.MapperMethod.execute(MapperMethod.java:69)
org.apache.ibatis.binding.MapperProxy.invoke(MapperProxy.java:53)
com.sun.proxy.$Proxy21.pageNum(Unknown Source)
cmcc.service.NewsService.pageNum(NewsService.java:23)
cmcc.web.font.NewsController.newsevents(NewsController.java:52)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
java.lang.reflect.Method.invoke(Method.java:498)
org.springframework.web.method.support.InvocableHandlerMethod.doInvoke(InvocableHandlerMethod.java:221)
org.springframework.web.method.support.InvocableHandlerMethod.invokeForRequest(InvocableHandlerMethod.java:137)
org.springframework.web.servlet.mvc.method.annotation.ServletInvocableHandlerMethod.invokeAndHandle(ServletInvocableHandlerMethod.java:110)
org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.invokeHandleMethod(RequestMappingHandlerAdapter.java:776)
org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.handleInternal(RequestMappingHandlerAdapter.java:705)
org.springframework.web.servlet.mvc.method.AbstractHandlerMethodAdapter.handle(AbstractHandlerMethodAdapter.java:85)
org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:959)
org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:893)
org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:967)
org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:858)
javax.servlet.http.HttpServlet.service(HttpServlet.java:635)
org.springframework.web.servlet.FrameworkServlet.service(FrameworkServlet.java:843)
javax.servlet.http.HttpServlet.service(HttpServlet.java:742)
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
sql报错把 SQL: select count(*) from t_news where type=? type 没值啊
这个问题本质上是数据库连接池的问题，如果再往深里讲是TCP连接失效导致连接不可用。这里需要了解下面几个名词的含义，首先是连接池，连接池里维护一组jdbc连接，这些连接在系统运行某个时间可能有一些连接被线程使用，也有一些连接处于空闲状态，这里当然也存在状态转换，空闲的连接会转换为被占用状态，被占用状态也会转换为空闲状态。其中被占用状态转换为空闲状态需要钝化，也就是初始化，同时钝化也会检查连接的状态是否还可以使用，如果发现连接异常就把连接销毁。jdbc连接本质就是TCP连接，这个连接什么时间会断掉，这是个概率问题，但是大致上我们知道如果mysql认为该连接长时间未使用服务器会主动断掉连接，如果使用proxy，它也会根据策略关闭连接。但是需要注意的是TCP连接是全双工工作，单方面关闭连接不会导致TCP连接关闭，也就是说服务器关闭了连接但是TCP连接还在，这种就很麻烦了，这样导致连接池中维护的连接会存在不健康的连接，也就是连接虽然还在但是已经不能用了。这时候我们从连接池中取出一个不健康的连接发请求是没问题的，但是一旦客户端调用read方法想读服务器返回数据就会抛出异常。这就是你上面返回一坨异常的根本原因。知道原因下面就好办了，本质上是连接坏掉了，两种处理手段：第一种是乐观解决方案，认为该问题不会频繁出现，等待出现了在解决，我们只需要catch住这个异常然后重新取一个连接就好了。这种方式可以给连接池配置一个自动重连机制。第二种是取出连接之前先检测一下连接健康，但是这种策略比较费劲，我建议使用第一种方案