Return-Path: Delivered-To: apmail-commons-issues-archive@locus.apache.org Received: (qmail 31407 invoked from network); 5 Feb 2008 14:32:32 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 5 Feb 2008 14:32:32 -0000 Received: (qmail 33403 invoked by uid 500); 5 Feb 2008 14:32:24 -0000 Delivered-To: apmail-commons-issues-archive@commons.apache.org Received: (qmail 32986 invoked by uid 500); 5 Feb 2008 14:32:22 -0000 Mailing-List: contact issues-help@commons.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: issues@commons.apache.org Delivered-To: mailing list issues@commons.apache.org Received: (qmail 32977 invoked by uid 99); 5 Feb 2008 14:32:22 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 05 Feb 2008 06:32:22 -0800 X-ASF-Spam-Status: No, hits=-100.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.4] (HELO brutus.apache.org) (140.211.11.4) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 05 Feb 2008 14:32:01 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 6C35071406F for ; Tue, 5 Feb 2008 06:32:09 -0800 (PST) Message-ID: <26249311.1202221929440.JavaMail.jira@brutus> Date: Tue, 5 Feb 2008 06:32:09 -0800 (PST) From: "Andrus Adamchik (JIRA)" To: issues@commons.apache.org Subject: [jira] Commented: (DBCP-244) Connection socket hangs sporadically in DBCP 1.2.2 but not 1.2.1 In-Reply-To: <32294787.1191968810561.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/DBCP-244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12565756#action_12565756 ] Andrus Adamchik commented on DBCP-244: -------------------------------------- I am observing a similar behavior with MySQL 5.0, dbcp-1.2.1, pool-1.2.... Also no visible deadlock in a thread dump. It happens once every few weeks, but usually simultaneously on multiple applications, so I suspect it is caused by temporary network outages... The problem of course is that the pool never recovers. Stuck threads look like this: btpool0-873" prio=10 tid=0x01001c50 nid=0x26a3 runnable [0x679fc000..0x679ffaf0] at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:129) at com.mysql.jdbc.util.ReadAheadInputStream.fill(ReadAheadInputStream.java:113) at com.mysql.jdbc.util.ReadAheadInputStream.readFromUnderlyingStreamIfNecessary(ReadAheadInputStream.java:160) at com.mysql.jdbc.util.ReadAheadInputStream.read(ReadAheadInputStream.java:188) - locked <0xab4f6b20> (a com.mysql.jdbc.util.ReadAheadInputStream) at com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:1902) at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:2351) at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:2862) at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1571) at com.mysql.jdbc.ServerPreparedStatement.serverExecute(ServerPreparedStatement.java:1124) - locked <0xac8430b0> (a java.lang.Object) at com.mysql.jdbc.ServerPreparedStatement.executeInternal(ServerPreparedStatement.java:676) at com.mysql.jdbc.PreparedStatement.executeQuery(PreparedStatement.java:1030) - locked <0xac8430b0> (a java.lang.Object) - locked <0xa69343f0> (a com.mysql.jdbc.ServerPreparedStatement) at org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:92) at org.apache.cayenne.access.jdbc.SelectAction.performAction(SelectAction.java:72) DBCP pool is wrapped in a Cayenne decorator, but this is still a DBCP pool with the following settings: cayenne.dbcp.maxActive=8 cayenne.dbcp.minIdle=1 cayenne.dbcp.maxIdle=4 cayenne.dbcp.validationQuery=select 1 from nhldb.division limit 1; cayenne.dbcp.testWhileIdle=true Can't even say that DBCP is here to blame, but still figured I provide this data point. > Connection socket hangs sporadically in DBCP 1.2.2 but not 1.2.1 > ---------------------------------------------------------------- > > Key: DBCP-244 > URL: https://issues.apache.org/jira/browse/DBCP-244 > Project: Commons Dbcp > Issue Type: Bug > Affects Versions: 1.2.2 > Environment: Fedora Core 3, MySQL 4.1.22. with the latest driver (5.07). Exceptions only occur in the "job processing" JVM, which sits idle for long periods of time and occasionally wakes up to interact with the database. > Reporter: ori > Fix For: 1.3 > > > I think I've traced an exception to DBCP's code. > Communication with the database is hanging sporadically in a production environment. If I don't set the socketTimeout property on the underlying connection, it will hang forever. With the socketTimeout property, I get the following exception: > ------- > com.mysql.jdbc.CommunicationsException: Communications link failure due to underlying exception: > ** BEGIN NESTED EXCEPTION ** > java.net.SocketTimeoutException > MESSAGE: Read timed out > STACKTRACE: > java.net.SocketTimeoutException: Read timed out > at java.net.SocketInputStream.socketRead0(Native Method) > at java.net.SocketInputStream.read(SocketInputStream.java:129) > at com.mysql.jdbc.util.ReadAheadInputStream.fill(ReadAheadInputStream.java:113) > at com.mysql.jdbc.util.ReadAheadInputStream.readFromUnderlyingStreamIfNecessary(ReadAheadInputStream.java:160) > at com.mysql.jdbc.util.ReadAheadInputStream.read(ReadAheadInputStream.java:188) > at com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:1994) > at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:2411) > at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:2916) > at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1631) > at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:1723) > at com.mysql.jdbc.Connection.execSQL(Connection.java:3250) > at com.mysql.jdbc.Statement.executeUpdate(Statement.java:1355) > at com.mysql.jdbc.Statement.executeUpdate(Statement.java:1270) > at org.apache.commons.dbcp.DelegatingStatement.executeUpdate(DelegatingStatement.java:228) > ... > ------- > It always happens in an infrequently used JVM (not an app server handling frequent connections). So it's likely the offending connection was asleep for a long time before the exception occurs. > I've confirmed that this issue only occurs using 1.2.2 and not 1.2.1. I've been looking through the changelogs but can't find anything that would cause this behavior. > Does somebody familiar with the codebase have any idea what change (1.2.1->1.2.2) could be causing this behavior? > Thanks -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.