java – C3P0 MySQL：读取通信包时出错

2023年4月3日 254次阅读

许多人遇到的错误与消息有关：

[Warning] Aborted connection 38 to db: 'database_name' user: 
'root' host: 'localhost' (Got an error reading communication packets)

这可以在MySQL日志中找到.在我的例子中,使用驱动程序com.mysql.jdbc.Driver和众所周知的C3P0池通过Java客户端本地访问数据库.我的MySQL服务器配置为接受大量连接,max_allowed_pa​​cket值设置为64M.以下是我的my.cnf文件(MySQL配置)的摘录：

[mysqld]
max_allowed_packet  = 64M
thread_concurrency      = 8
thread_cache_size       = 8
thread_stack        = 192K
query_cache_size = 0
query_cache_type = 0
max_connections = 1024
back_log = 50
innodb_thread_concurrency = 6
innodb_lock_wait_timeout = 120
log_warnings

和

[mysqldump]
quick
quote-names
max_allowed_packet  = 64M

我的数据库中的表User具有以下简单结构：

CREATE TABLE `User` (
  `uid` varchar(255) COLLATE utf8_bin NOT NULL,
  `name` varchar(255) COLLATE utf8_bin DEFAULT NULL,
  `mail` varchar(255) COLLATE utf8_bin DEFAULT NULL,
  `password` varchar(255) COLLATE utf8_bin DEFAULT NULL,
  `created` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `maxParallelTasks` tinyint(4) NOT NULL DEFAULT '10',
  `maxModels` int(11) NOT NULL DEFAULT '2000',
  `maxBibTeX` int(11) NOT NULL DEFAULT '2000',
  PRIMARY KEY (`uid`) USING BTREE,
  UNIQUE KEY `mail` (`mail`) USING BTREE,
  KEY `uid` (`uid`) USING BTREE,
  KEY `index_user_name` (`name`) USING BTREE,
  KEY `index_user_mail` (`mail`) USING BTREE,
  KEY `index_user_maxModels` (`maxModels`) USING BTREE,
  KEY `index_user_maxBibTeX` (`maxBibTeX`) USING BTREE,
  KEY `index_user_maxParallelTasks` (`maxParallelTasks`) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin

当我使用mysql客户端(即mysql -u root -p)在该表中插入一个值时,我在日志中没有警告.但是,当尝试相同的Java端时,上述警告会出现在日志中很多次！所以,在Java端,我的连接是从C3P0连接池中提取的,配置如下：

datasource = new ComboPooledDataSource();
datasource.setJdbcUrl(connectURI);
datasource.setMaxPoolSize(1000);
datasource.setMinPoolSize(20);
datasource.setInitialPoolSize(50);
datasource.setNumHelperThreads(6);
datasource.setTestConnectionOnCheckin(true);
datasource.setTestConnectionOnCheckout(true);

声明首先准备：

PreparedStatement ps = connection.prepareStatement(getSql());

然后参数化：

ps.setString(1, user.getUid());
ps.setString(2, user.getName());
ps.setString(3, user.getMail());
ps.setString(4, user.getHashedPass());

然后执行：

int update = ps.executeUpdate();

然后关闭准备好的声明：

ps.close();

并且SQL连接已关闭：

if (connection != null) {
            try {
                if (!connection.isClosed()) {
                    connection.close();
                }
            } catch (SQLException ex) {
                throw new DbException(ex);
            }
}

整个程序似乎(对我而言)是合法的.根据http://dev.mysql.com/doc/refman/5.0/en/communication-errors.html的MySQL手册,这个警告可能意味着：

The client program did not call
mysql_close() before exiting.

或者那个：

The client program ended abruptly in
the middle of a data transfer.

出于我的应用程序的目的,我已经使用C3P0使用200多个并行线程在这个数据库中进行写入和读取,并且在检查数据实际上已经转移到数据库并从数据库中检索时,我没有内存泄漏.有没有其他人有类似的经历？

最后,我包括我的MySQL版本以及可能对故障排除有用的其他信息：

mysql> show variables like "%version%";
+-------------------------+-------------------+
| Variable_name           | Value             |
+-------------------------+-------------------+
| protocol_version        | 10                | 
| version                 | 5.1.37-1ubuntu5.5 | 
| version_comment         | (Ubuntu)          | 
| version_compile_machine | x86_64            | 
| version_compile_os      | debian-linux-gnu  | 
+-------------------------+-------------------+

和

Java version: 1.6.0_22, (build 1.6.0_22-b04)

最佳答案 好吧,很高兴看到一个带有恰当数量的信息的问题,这些信息暗示了系统可能遇到问题的可能位置.这是我要检查的内容：

>在关闭Connection对象之前尝试关闭PreparedStatement对象,并验证是否已解决问题.这可能听起来没必要,但在某些JDBC驱动程序的情况下是必需的,最明显的是Oracle(也可能是MySQL).理由是Connection对象并没有真正关闭,特别是如果ResultSet和Statement对象之类的派生对象没有首先被关闭(按照提到的顺序).在某种程度上,这是由于JDBC驱动程序的编写方式.
>验证所涉及的机器是否可以实际处理您希望它们的负载.如果底层网络基础架构根本无法处理指定数量的连接,则很可能会断开连接.如果第一个建议无效,您可能需要查看wireshark转储并从中得出推论.
>使用debugUnreturnedConnectionStackTraces标志来检测任何连接池泄漏.这也要求unreturnedConnectionTimeout为正.该标志确保为应用程序未将连接返回池的条件提供堆栈跟踪.堆栈跟踪将指示最初保留连接的代码中的点.

点赞