cause

A field of online data is empty, which is calculated by running and saving (low voice force: using saved data is really unfriendly).

process

1. View stored procedure logic
   Call the stored value through parameter test to check whether there is return value. There is no problem with the stored value (how to test the stored value can be Baidu by yourself).
2. View online logs

org.springframework.jdbc.UncategorizedSQLException: CallableStatementCallback; uncategorized SQLException for SQL []; SQL state [null]; error code [0]; Connection has already been closed.; nested exception is java.sql.SQLException: Connection has already been closed.
  at org.springframework.jdbc.support.AbstractFallbackSQLExceptionTranslator.translate(AbstractFallbackSQLExceptionTranslator.java:90)
  at org.springframework.jdbc.support.AbstractFallbackSQLExceptionTranslator.translate(AbstractFallbackSQLExceptionTranslator.java:82)
  at org.springframework.jdbc.support.AbstractFallbackSQLExceptionTranslator.translate(AbstractFallbackSQLExceptionTranslator.java:82)
  at org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:1105)

A connection closed issue was found.
At this time, it is doubted whether the IOPS of the online database is too high or the CPU utilization is too high, which leads to the sql execution time is too long and the timeout state occurs. However, if this is the case, a large number of such exceptions should occur, which affects the normal use of the system, so it is not the problem.

Retrieve the log according to the Connection has already been closed keyword, and check the code if there are any exceptions.

Found that the connection was disconnected before calling the save. There is a call to websock to throw an exception before:

java.net.SocketTimeoutException: Read timed out

According to the log, the interface starts to request and throws an exception, which takes 15+mini. When calling the websock interface, the timeout is not set. Check the connection pool configuration:

     tomcat: 
     initial-size: 10
     min-idle: 10   #The minimum number of connections that should always be kept. If the validation query fails, the connection pool shrinks the value. The default value is taken from initialSize:10 (see testWhileIdle).
     max-active: 200  #The maximum number of active connections that can be allocated at the same time. 100 by default
     max-idle: 10  #The maximum number of connections that the pool should always keep. The default is maxActive:100. The idle connection will be checked periodically (if this function is enabled), and the idle connection with a latency longer than minevictableidletimmillis will be released. (refer to testWhileIdle)
     max-wait: 30000    #The maximum time, in milliseconds, that the connection pool waits (when no connection is available) to return a connection before throwing an exception. Default is 30000 (30 seconds)
     validation-query: select 1 from dual
     test-while-idle: true  #The default value of this property is false to verify the object through the free object cleaner, if any. If object validation fails, it is purged from the pool. Validation query must be set
     test-on-borrow: false  #true by default
     time-between-eviction-runs-millis: 5000 #Sleep time (in milliseconds) between idle connection verification / clearing thread runs. Cannot be less than 1 second. This value determines how often we check for free connections, discard connections, and verify free connections. 5000 by default (5 seconds)
     remove-abandoned-timeout: 180  #(integer value) the number of timeout seconds before the discarded connection (still in use) can be cleared. The default is 60 (60 seconds). This value should be set to the longest running query the application may have
     remove-abandoned: true   #This value is a Flag value indicating that if the connection time exceeds removeAbandonedTimeout, the discarded connection will be cleared. If the value is set to true, if the connection time is greater than removeAbandonedTimeout, the connection will be considered as abandoned and should be cleared. If the application fails to close the connection, set the value to true to recover the database connection of the application. See also logabandone. The default is false.

tomcat's database connection pool is used, which is configured to clear the connection after 180 seconds of idle.

Conclusion:

The websock interface request did not set a timeout, which resulted in connection recycling.