5

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

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

可以在 MySQL 日志中找到。在我的例子中，数据库是通过 java 客户端使用驱动程序和众所周知的 C3P0 池在本地访问的。com.mysql.jdbc.Driver我的 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

当我INSERT使用 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 手册，此警告可能意味着：

客户端程序在退出前没有调用 mysql_close()。

或者那个：

客户端程序在数据传输过程中突然结束。

出于我的应用程序的目的，我使用 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)
4

2 回答 2

1

好吧，很高兴看到一个包含适量信息的问题，这些信息将暗示系统可能遇到问题的地方。这是我要检查的内容：

  • PreparedStatement在关闭对象之前尝试关闭Connection对象，并验证这是否解决了问题。这听起来可能没有必要，但在某些 JDBC 驱动程序的情况下是必需的，尤其是 Oracle（也可能是 MySQL）。基本原理是Connection对象并没有真正关闭，特别是如果派生对象（如ResultSet和Statement对象）没有首先关闭（按提到的顺序）。部分原因在于 JDBC 驱动程序的编写方式。
  • 验证所涉及的机器是否可以实际处理您希望它们处理的负载。如果底层网络基础设施根本无法处理指定数量的连接，那么连接很可能会被丢弃。如果第一个建议没有帮助，您可能想查看一个 wireshark 转储并从中得出推论。
  • 使用该debugUnreturnedConnectionStackTraces标志来检测任何连接池泄漏。这也要求 unreturnedConnectionTimeout 为正数。该标志确保为应用程序不将连接返回池的情况提供堆栈跟踪。堆栈跟踪将指示代码中最初保留连接的位置。
于 2011-02-14T15:33:34.120 回答
1

试图更深入地调查此警告的原因...

首先，我注意到我在日志文件中收到的警告消息的数量等于或非常接近指定的最小池大小，datasource.setMinPoolSize(int);而为了测试而将初始池大小设置为每次等于最小大小。

此外，使用调试器并逐步执行语句，我有时间观察到单元测试完成后会立即记录警告。这些事实使我得出结论，由 C3P0 汇集的连接实际上在被丢弃之前并未关闭。需要的是一旦不再使用数据源就关闭数据源来调用该方法com.​mchange.​v2.​c3p0.​impl.​AbstractPoolBackedDataSource#close()。当然只有在单元测试结束时这样做才有意义，所以在我的例子中，修改看起来像这样：

@AfterClass
public static void tearDownClass() throws Exception {
  // Close the pool 
  DataSourceFactory.getInstance().close();
}

在我的应用程序中，我添加了一个关闭挂钩，以便数据源在执行停止之前关闭。在此之前，池连接保持不变，驱动程序必须关闭它们，从而在 MySQL 日志中引起警告。这解决了所有 INSERT 操作的问题，但不幸的是，不适用于 SELECT 操作。请注意，我关闭了所有结果集、语句、准备好的语句和连接，并使用FindBugs（一种静态分析工具）检查了我的源代码。一种解决方法让我怀疑 C3P0 又出了问题，但我不能确定。因此，以下内容使警告消失...

@AfterClass
public static void tearDownClass() throws Exception {
  Thread.sleep(100000); // wait for 100 secs
  DataSourceFactory.getInstance().close();
}

请注意，在 100 秒的时间结束（并且数据源工厂关闭）之前，日志中不会出现任何警告！所以，这datasource.close()就是导致他们...

于 2011-02-15T15:06:04.753 回答