Access denied |
used Cloudflare to restrict access
Please enable cookies.
What happened?
The owner of this website () has banned your access based on your browser's signature (3bc2e-ua98).君，已阅读到文档的结尾了呢~~
gns3保存配置,gns3 host配置,gns3 asa配置,gns3 pc配置,gns3 配置,cisco保存配置,h3c保存配置命令,gns3保存配置,iptables保存配置,华为保存配置命令
扫扫二维码，随身浏览文档
手机或平板扫扫即可继续访问
gns3如何无法保存路由器配置解决办法
举报该文档为侵权文档。
举报该文档含有违规或不良信息。
反馈该文档无法正常浏览。
举报该文档为重复文档。
推荐理由：
将文档分享至：
分享完整地址
文档地址：
粘贴到BBS或博客
flash地址：
支持嵌入FLASH地址的网站使用
html代码：
&embed src='/DocinViewer--144.swf' width='100%' height='600' type=application/x-shockwave-flash ALLOWFULLSCREEN='true' ALLOWSCRIPTACCESS='always'&&/embed&
450px*300px480px*400px650px*490px
支持嵌入HTML代码的网站使用
您的内容已经提交成功
您所提交的内容需要审核后才能发布，请您等待！
3秒自动关闭窗口9872人阅读
hibernate 有自带的连接池，但大家用起来颇有微词，因为其稳定性以及性能都不太好。c3p0 连接池的性能和稳定性久经考验，所以用 hibernate 的朋友一般都使用 c3p0 的连接池。那么是不是把 c3p0 的包导进来，然后 hibernate.cfg.xml 里把 c3p0 的各种属性加进来就万事大吉了呢？不见得，很可能你的项目上线以后，发现你的连接池不仅性能低下，而且可靠性差，c3p0 并没有表现出它传说中应该具有的那些特性。你在咒骂 c3p0 的可靠性以及性能的时候，有没有想过你用的很可能还是 hibernate 默认的连接池，因为你的 c3p0 的那些配置压根儿就没起作用呢？你有没有考虑过，怎么样才能让你配置的 hibernate 中 c3p0 配置真正起作用？怎样验证你的 c3p0 配置真正起了作用了？本文结合作者亲自经历的一次 java.net.SocketException: Connection reset 故障的排除体验，来回答一下这些问题。本文所用 mysql 版本是 5.0， hibernate 版本是 3.3.2，c3p0 版本是 0.9.1.1：笔者的项目 dao 层组合是 hibernate+c3p0+mysql，hibernate.cfg.xml 中 c3p0 连接池配置如下：
&property name=&hibernate.c3p0.max_size&&10&/property&
&property name=&hibernate.c3p0.min_size&&5&/property&
&property name=&hibernate.c3p0.checkoutTimeout&&15000&/property&
&property name=&hibernate.c3p0.max_statements&&200&/property&
&property name=&hibernate.c3p0.idle_test_period&&0&/property&
&property name=&hibernate.c3p0.acquire_increment&&1&/property&
&property name=&hibernate.c3p0.validate&&true&/property&
&property name=&hibernate.c3p0.timeout&&0&/property&上线以后，发现偶尔会有以下错误：org.hibernate.exception.JDBCConnectionException: Cannot open connection at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:97) at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:66) at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:52) at org.hibernate.jdbc.ConnectionManager.openConnection(ConnectionManager.java:449) at org.hibernate.jdbc.ConnectionManager.getConnection(ConnectionManager.java:167) at org.hibernate.jdbc.JDBCContext.connection(JDBCContext.java:142) at org.hibernate.transaction.JDBCTransaction.begin(JDBCTransaction.java:85) at org.hibernate.impl.SessionImpl.beginTransaction(SessionImpl.java:1354) at sun.reflect.GeneratedMethodAccessor263.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.hibernate.context.ThreadLocalSessionContext$TransactionProtectionWrapper.invoke(ThreadLocalSessionContext.java:342) at com.sun.proxy.$Proxy23.beginTransaction(Unknown Source) at com.defonds.dao.PayAntharDao.updateBalance(PayAntharDao.java:595) at com.defonds.interImpl.BatchLogAdmin$BatchUpdateThread.run(BatchLogAdmin.java:49) at java.lang.Thread.run(Thread.java:745)Caused by: com.mysql.jdbc.municationsException: Communications link failureThe last packet successfully received from the server was 5,226,622 milliseconds ago. &The last packet sent successfully to the server was 1 milliseconds ago. at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:526) at com.mysql.jdbc.Util.handleNewInstance(Util.java:411) at com.mysql.jdbc.SQLError.createCommunicationsException(SQLError.java:1116) at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3589) at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3478) at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4019) at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2490) at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2651) at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2677) at com.mysql.jdbc.ConnectionImpl.setTransactionIsolation(ConnectionImpl.java:5315) at org.hibernate.connection.DriverManagerConnectionProvider.getConnection(DriverManagerConnectionProvider.java:126) at org.hibernate.jdbc.ConnectionManager.openConnection(ConnectionManager.java:446) ... 12 moreCaused by: java.net.SocketException: Connection reset at java.net.SocketInputStream.read(SocketInputStream.java:196) at java.net.SocketInputStream.read(SocketInputStream.java:122) at com.mysql.jdbc.util.ReadAheadInputStream.fill(ReadAheadInputStream.java:114) at com.mysql.jdbc.util.ReadAheadInputStream.readFromUnderlyingStreamIfNecessary(ReadAheadInputStream.java:161) at com.mysql.jdbc.util.ReadAheadInputStream.read(ReadAheadInputStream.java:189) at com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:3036) at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3489) ... 20 more一开始只是一些定时查询的线程曝出这个错误，因为没有影响业务，所以也没太在意。后来项目变更，为了增强用户体验，一些更新操作由同步等待，换为异步操作，也就是主线程立即返回给用户结果，另起线程去更新。响应速度是提上去了，但是这个更新却偶尔失败，原因就是上边那个 Connection reset 故障，这个更新失败频率太高了，基本每天一次(大都是早上第一次出现频率最高)，造成客户不满。虽然手头还有巨多任务，但客户至上。优先级拉高。异常信息里边说的很明白，造成这个故障的原因是数据库服务器的超时断开机制，也就是说如果你没有任何查询语句(这里，增删改也属于查询的范畴)，超过数据库配置的时间( &wait_timeout& 默认为八小时)后，就把当前连接断开。而连接池却不知道，还认为当前连接是有效的，当有新的 sql 过来时，启用当前数据库已经废弃的连接，造成以上结果。怎么办呢？增大数据库超时治标不治本；连接字符串加上 &autoReconnect=true&failOverReadOnly=false&maxReconnects=10 也无济于事；加上以下空闲验证也不起作用：&property name=&hibernate.c3p0.idle_test_period&&120&/property&
&property name=&hibernate.c3p0.validate&&true&/property&
&property name=&hibernate.c3p0.preferredTestQuery&&select 1&/property&c3p0 的稳定性应该没这么差吧？会不会是根本就没用 c3p0 的连接池呢？我们开始怀疑我们对 c3p0 的配置对不对。于是我们用 SHOW PROCESSLIST; 命令对我们的连接池进行验证，发现果然没有用上 c3p0 的配置(我们配的连接数最小为 5)：原因在哪里呢？hibernate 核心包里有以下类：可见 hibernate 原生态是支持 c3p0 的。那么怎么才能让 hibernate 去认这些配置呢？查看 hibernate 核心包里的 org.hibernate.connection.ConnectionProviderFactory 类的源码，可以看到以下注释：Instantiates a connection provider given either System properties or a java.util.Properties instance. The ConnectionProviderFactory first attempts to find a name of a ConnectionProvider subclass in the property hibernate.connection.provider_class. If missing, heuristics are used to choose either DriverManagerConnectionProvider, DatasourceConnectionProvider, C3P0ConnectionProvider or DBCPConnectionProvider.&事情到了这里，已经很清晰明朗了：如果我们没有配置 ConnectionProvider 的实现类，hibernate 默认去找 DriverManagerConnectionProvider、DatasourceConnectionProvider、C3P0ConnectionProvider 或者 DBCPConnectionProvider 其中的一个作为连接池的实现。通过上面的日志可以看出，很不幸，hibernate 没有去找 C3P0ConnectionProvider，它找的是 DriverManagerConnectionProvider。既然找到了问题症兆所在，接下来的事就顺理成章了，我们只需把 C3P0ConnectionProvider 加到 hibernate 配置里即可，于是我们 hibernate 连接池配置变成了下面的样子：&property name=&hibernate.connection.provider_class&&org.hibernate.connection.C3P0ConnectionProvider&/property&
&property name=&hibernate.c3p0.max_size&&10&/property&
&property name=&hibernate.c3p0.min_size&&5&/property&
&property name=&hibernate.c3p0.checkoutTimeout&&15000&/property&
&property name=&hibernate.c3p0.max_statements&&200&/property&
&property name=&hibernate.c3p0.idle_test_period&&120&/property&
&property name=&hibernate.c3p0.timeout&&300&/property&
&property name=&hibernate.c3p0.acquire_increment&&1&/property&
&property name=&hibernate.c3p0.validate&&true&/property&
&property name=&hibernate.c3p0.preferredTestQuery&&select 1&/property&部署上去。世界安静了，客户急匆匆的电话声没了：上个月的 18 日部署上这个配置，直到作者发本篇博客为止，再也没有遇见 Connection reset 故障。后记其实还有一个办法验证你的 c3p0 有没有配置成功，以上异常信息里有这一句：at org.hibernate.connection.DriverManagerConnectionProvider.getConnection(DriverManagerConnectionProvider.java:126)这也说明了按照当时的配置，hibernate 用的实际是 hibernate 自己的连接池，不是 c3p0 的。
&&相关文章推荐
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：4663964次
积分：36463
积分：36463
排名：第124名
原创：240篇
转载：35篇
译文：160篇
评论：1504条
(1)(1)(4)(6)(4)(5)(5)(5)(6)(5)(1)(3)(2)(2)(3)(2)(2)(1)(1)(1)(1)(3)(7)(4)(3)(5)(10)(10)(2)(2)(5)(3)(4)(4)(7)(4)(2)(1)(1)(6)(6)(4)(3)(4)(2)(21)(10)(3)(3)(5)(4)(1)(1)(3)(5)(3)(1)(1)(1)(1)(1)(3)(5)(15)(10)(1)(1)(2)(1)(2)(4)(3)(2)(1)(2)(1)(1)(1)(1)(3)(1)(1)(1)(1)(5)(3)(3)(1)(4)(1)(3)(11)(7)(7)(13)(7)(8)(1)(4)(6)(14)(16)(25)(1)(1)(1)(1)(1)(1)(1)26329人阅读
IP/TCP（2）
JVM 源码分析（51）
在Java中常看见的几个connection rest exception,&Broken pipe, Connection reset，Connection reset by peer
Socked reset case&
Linux中会有2个常见的sock reset 情况下的错误代码
ECONNRESET
&&&&&&&&& 该错误被描述为“connection reset by peer”，即“对方复位连接”，这种情况一般发生在服务进程较客户进程提前终止。当服务进程终止时会向客户 TCP 发送 FIN 分节，客户 TCP 回应 ACK，服务 TCP 将转入 FIN_WAIT2 状态。此时如果客户进程没有处理该 FIN （如阻塞在其它调用上而没有关闭 Socket 时），则客户 TCP 将处于 CLOSE_WAIT 状态。当客户进程再次向 FIN_WAIT2 状态的服务 TCP 发送数据时，则服务 TCP 将立刻响应
RST。一般来说，这种情况还可以会引发另外的应用程序异常，客户进程在发送完数据后，往往会等待从网络IO接收数据，很典型的如 read 或 readline 调用，此时由于执行时序的原因，如果该调用发生在 RST 分节收到前执行的话，那么结果是客户进程会得到一个非预期的 EOF 错误。此时一般会输出“server terminated prematurely”－“服务器过早终止”错误。
&&&&&&&&& 错误被描述为“broken pipe”，即“管道破裂”，这种情况一般发生在客户进程不理会（或未及时处理）Socket 错误，继续向服务 TCP 写入更多数据时，内核将向客户进程发送 SIGPIPE 信号，该信号默认会使进程终止（此时该前台进程未进行 core dump）。结合上边的 ECONNRESET 错误可知，向一个 FIN_WAIT2 状态的服务 TCP（已 ACK 响应 FIN 分节）写入数据不成问题，但是写一个已接收了 RST 的 Socket 则是一个错误。
Java 中的socket input stream/output stream 的处理
先看代码片段
SocketInputStream.c
switch (errno) {
case ECONNRESET:
case EPIPE:
JNU_ThrowByName(env, &sun/net/ConnectionResetException&,
&Connection reset&);
SocketOutputStream.c
if (errno == ECONNRESET) {
JNU_ThrowByName(env, &sun/net/ConnectionResetException&,
&Connection reset&);
NET_ThrowByNameWithLastError(env, &java/net/SocketException&,
&Write failed&);
可以看到java 在读和写的情况关于EPIPE的情况是处理不一样的
在read 的情况中，Reset 是全部抛出 ConnectionResetException, 提示的错误信息是 Connection Reset
在write的情况下，Reset 对ECONNRESET的是抛出ConnectionResetException, 而对EPIPE 抛出的是SocketException ,错误信息是Broken pipe
如何打印出信息Broken pipe
SIGPIPE信号处理函数
当在收到reset包后，如果在读写socket,会出现错误EPIPE,同时经常收到SIGPIPE信号
在程序中可以看到java 并没有对write的情况下没有处理错误EPIPE,开始的时候错误的以抛出的异常是信号处理函数抛出的
先来看一下关于信号SIGPIPE的处理函数,在Linux::install_signal_handlers 里面调用函数
set_signal_handler(SIGSEGV, true);
set_signal_handler(SIGPIPE, true);
set_signal_handler(SIGBUS, true);
set_signal_handler(SIGILL, true);
set_signal_handler(SIGFPE, true);
set_signal_handler(SIGXFSZ, true);
而函数set_signal_handler,中对对应的信号处理函数是signalHandler
sigAct.sa_handler = SIG_DFL;
if (!set_installed) {
sigAct.sa_flags = SA_SIGINFO|SA_RESTART;
sigAct.sa_sigaction = signalH
sigAct.sa_flags = SA_SIGINFO|SA_RESTART;
}最终还是调用了函数&JVM_handle_linux_signal
在X86架构下， 函数JVM_handle_linux_signal
extern &C& int
JVM_handle_linux_signal(int sig,
siginfo_t* info,
void* ucVoid,
int abort_if_unrecognized) {
ucontext_t* uc = (ucontext_t*) ucV
Thread* t = ThreadLocalStorage::get_thread_slow();
SignalHandlerMark shm(t);
// Note: it's not uncommon that JNI code uses signal/sigset to install
// then restore certain signal handler (e.g. to temporarily block SIGPIPE,
// or have a SIGILL handler when detecting CPU type). When that happens,
// JVM_handle_linux_signal() might be invoked with junk info/ucVoid. To
// avoid unnecessary crash when libjsig is not preloaded, try handle signals
// that do not require siginfo/ucontext first.
if (sig == SIGPIPE || sig == SIGXFSZ) {
// allow chained handler to go first
if (os::Linux::chained_handler(sig, info, ucVoid)) {
if (PrintMiscellaneous && (WizardMode || Verbose)) {
char buf[64];
warning(&Ignoring %s - see bugs 4229104 or &,
os::exception_name(sig, buf, sizeof(buf)));
对信号SIGPIPE 使用了chained handler处理，也就是使用了系统的原来信号处理函数，也就证明了异常并不是信号处理函数抛出的
NET_ThrowByNameWithLastError函数
既然不是信号处理函数抛出的异常，继续查看原来的outputstream的程序
if (errno == ECONNRESET) {
JNU_ThrowByName(env, &sun/net/ConnectionResetException&,
&Connection reset&);
NET_ThrowByNameWithLastError(env, &java/net/SocketException&,
&Write failed&);
也就是else 的情况，那么针对EPIPE的错误，java抛出的socketexception, 错误信息是Write failed ，事实上我们可以看到的却是SockedException,异常对对上了， 但信息显示是Broken pipe，而不是Write failed.
关键点就在函数&NET_ThrowByNameWithLastError
NET_ThrowByNameWithLastError(JNIEnv *env, const char *name,
const char *defaultDetail) {
char errmsg[255];
sprintf(errmsg, &errno: %d, error: %s\n&, errno, defaultDetail);
JNU_ThrowByNameWithLastError(env, name, errmsg);
函数JNU_ThrowByNameWithLastError
JNIEXPORT void JNICALL
JNU_ThrowByNameWithLastError(JNIEnv *env, const char *name,
const char *defaultDetail)
char buf[256];
int n = JVM_GetLastErrorString(buf, sizeof(buf));
if (n & 0) {
jstring s = JNU_NewStringPlatform(env, buf);
if (s != NULL) {
jobject x = JNU_NewObjectByName(env, name,
&(Ljava/lang/S)V&, s);
if (x != NULL) {
(*env)-&Throw(env, x);
if (!(*env)-&ExceptionOccurred(env)) {
JNU_ThrowByName(env, name, defaultDetail);
程序可以看到先显示 JVM_GetLastErrorString 的信息，如果信息是空的情况下才显示defaultDetail的异常信息，也就是开始对应的Write failed!
JVM_GetLastErrorString 使用hpi::lasterror ,也就是函数sysGetLastErrorString 在linux和solaris 是一样的
sysGetLastErrorString(char *buf, int len)
if (errno == 0) {
const char *s = strerror(errno);
int n = strlen(s);
if (n &= len) n = len - 1;
strncpy(buf, s, n);
buf[n] = '\0';
原来是strerror(errno) ,也就是直接显示linux kernel 对应这个error number 的错误内容
结论：Broken pipe 是内核对应的错误信息，并不是java自己提供的信息
&&相关文章推荐
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：423448次
积分：4922
积分：4922
排名：第6114名
原创：97篇
评论：72条
(1)(1)(2)(3)(2)(6)(5)(2)(1)(3)(6)(1)(7)(3)(1)(1)(1)(3)(1)(6)(5)(1)(2)(1)(1)(1)(1)(1)(1)(1)(2)(3)(1)(4)(2)(2)(1)(2)(2)(4)(1)(2)(1)(1)(2)