You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Alexey Sergeev (JIRA)" <ji...@apache.org> on 2010/07/01 16:34:53 UTC

[jira] Commented: (DBCP-244) Connection socket hangs sporadically in DBCP 1.2.2 but not 1.2.1

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

Alexey Sergeev commented on DBCP-244:
-------------------------------------

 The probem is reproducibe  - that's for sure!
To reach the problem you need to reconfigure MySQL server a little. I.e. update my.ini (on Windows) or my.cnf (on Linux) and set idle conection timeout to  smaller value:
{code}
[mysqld]
...
# use one minute timeout
wait_timeout=60 
...
{code}

Default value is 8 hours so it is not so eacsy to reproduce "broken pipe" error so easy (not so feasible).

So if you run you application (with commons-dbcp-1.2.2.jar) on mysql configured in this way you will be able to get the exception ().

I've tried to use additional properties like maxOpenPreparedStatements, validationQuery nd etc. But it does NOT help!

But one this that works ALWAYS - is using commons-dbcp-1.2.1.jar.

So guys,  could you fix this REAL problem and provide new release?! Or at least explayn what has been changed in new DBCP and how exacly it could be properly configured?


> 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.