Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Message-ID: <3853704.1192198671150.JavaMail.jira@brutus>
Date: Fri, 12 Oct 2007 07:17:51 -0700 (PDT)
From: "ori (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Subject: [jira] Issue Comment Edited: (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


    [ https://issues.apache.org/jira/browse/DBCP-244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12534297 ] 

os111 edited comment on DBCP-244 at 10/12/07 7:16 AM:
----------------------------------------------------

Correct--those are the only configuration parameters I specify.

There is no indication of a lock. Furthermore, there's no indication that the query/update was ever executed. It never shows up in MySQL's "SHOW PROCESSLIST" command.

This issue can appear on any query/statement without any pattern (MyISAM or InnoDB tables, INSERT or SELECT). 

I use standard JDBC programming practices when accessing statements/connections.

The DataSource is created once per application like this:

dataSource = org.apache.commons.dbcp.BasicDataSourceFactory.createDataSource( commonsDbProps );

Connections are obtained like this:

dataSource.getConnection();

All JDBC calls are executed in a try/finally block that closes result sets, statments, and connections immediately after they're used in the finally block (in that order).

I'm confident that I'm not misusing any APIs. 

The fact that I can eliminate this issue by switching to another version of DBCP would indicate my application code and database setup are not the problem (but I could be wrong).

I think the most important clue we have is that I'm using the exact same setup on my Tomcat server with DBCP 1.2.2 and have never experienced this issue. That server is under heavy load all the time so Connections never sit idle (up to 2.5M dynamic pageviews per day).

The JVM having the issues is running Quartz, a scheduling library (like cron jobs but in Java) so it can sit idle for a few hours, then wake up and access the database, then sleep again.

      was (Author: os111):
    Correct--those are the only configuration parameters I specify.

There is no indication of a lock. Furthermore, there's no indication that the query/update was ever executed. It never shows up in MySQL's "SHOW PROCESSLIST" command.

This issue can appear on any query/statement without any pattern (MyISAM or InnoDB tables, INSERT or SELECT). 

I use standard JDBC programming practices when accessing statements/connections.

The DataSource is created once per application like this:

dataSource = org.apache.commons.dbcp.BasicDataSourceFactory.createDataSource( commonsDbProps );

Connections are obtained like this:

dataSource.getConnection();

All JDBC calls are executed in a try/finally block that closes result sets, statments, and connections immediately after they're used in the finally block (in that order).

I'm confident that I'm not misusing any APIs. 

The fact that I can eliminate this issue by stitching to another version of DBCP would indicate my application code and database setup are not the problem (but I could be wrong).

I think the most important clue we have is that I'm using the exact same setup on my Tomcat server with DBCP 1.2.2 and have never experienced this issue. That server is under heavy load all the time so Connections never sit idle (up to 2.5M dynamic pageviews per day).

The JVM having the issues is running Quartz, a scheduling library (like cron jobs but in Java) so it can sit idle for a few hours, then wake up and access the database, then sleep again.
  
> 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
>
> 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.