| Bug #7195 | broken pipe: | ||
|---|---|---|---|
| Submitted: | 11 Dec 2004 16:00 | Modified: | 29 Apr 2015 14:00 |
| Reporter: | Mark Swanson | Email Updates: | |
| Status: | Can't repeat | Impact on me: | |
| Category: | Connector / J | Severity: | S1 (Critical) |
| Version: | 3.1.5-gamma | OS: | Linux (Linux/Java 5) |
| Assigned to: | Alexander Soklakov | CPU Architecture: | Any |
[11 Dec 2004 17:12]
Mark Matthews
GA doesn't have any known open bugs (that aren't waiting for feedback from the filer), are there any specific bugs you can point to, or are these bugs you're running into but have not filed?
[11 Dec 2004 17:16]
Mark Matthews
I see you're using a prepared statement with server-side support. Unfortunately, auto-reconnect has _not_ been added to server-side prepared statements, due to issues with making this work with the server (we'll document that). You should change your reconnect logic to _throw_away_ the current connection, and try with a new one, rather than using the auto-reconnect functionality in the JDBC driver. This is probably a future-proof move, as the JDBC-4.0 spec is looking at requiring this for high-availability JDBC drivers (i.e. no auto-reconnect, the app must 'throw away' the current connection), as not all vendors can support an auto-reconnectable java.sql.Connection.
[11 Dec 2004 20:00]
Mark Swanson
Thank you for the instructions on how to handle this properly. I have made the changes and things appear to be working well. I'll post back if I encounter any futher problems.
[25 Oct 2005 15:31]
Zia Khan
Hi Mark,
I am getting the exact same problem but I am using Connection pool in Jboss 3.2.6 Application Server. I am not sure how I can go about fixing this problem as I am not making the JDBC connection directly but the container is.
Any help would be appreciated.
Thanks,
Zia Khan
java.net.SocketException: Broken pipe
at java.net.SocketOutputStream.socketWrite0(Native Method)
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)
at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:66)
at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:124)
at com.mysql.jdbc.MysqlIO.send(MysqlIO.java:2689)
at com.mysql.jdbc.MysqlIO.send(MysqlIO.java:2618)
at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1551)
at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:1665)
at com.mysql.jdbc.Connection.execSQL(Connection.java:2978)
at com.mysql.jdbc.Connection.execSQL(Connection.java:2902)
at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:930)
at com.mysql.jdbc.PreparedStatement.executeQuery(PreparedStatement.java:1024)
at org.jboss.resource.adapter.jdbc.WrappedPreparedStatement.executeQuery(WrappedPreparedStatement.java:314)
at com.rni.provisioning.service.util.ServiceReaderHelper.getAllXMLs(ServiceReaderHelper.java:89)
[8 Jan 2006 11:11]
Phil Haigh
I am experiencing a similar problem - again, my connection pool is acquiring connections for me. Interestingly, the Tomcat parameters to control the pool seem to have little or no impact on this problem. So setting things like testOnBorrow and testOnReturn - and even discarding connections that are not used for at least 10s - cannot influence what appears to be internal caching of connections within the JDBC driver code. As the description talks about this problem in relation to PreparedStatement code, I shall switch to using Statement instead and see if this resolves the problem. And then I shall take a look at the JDBC code and see if I can't fix the caching problem myself.
[10 Jan 2006 9:29]
Phil Haigh
An update on my previous post. Switching away from PreparedStatement to Statement was not an option because my persistence library makes use of lots of PreparedStatement features. So, I've tried creating a Statement object and executing a basic SELECT statement as I retrieve a connection from the pool, my working theory being that if the first use of the connection is not a PreparedStatement then the problem would go away. If the statement fails then the connection is returned to the pool (where hopefully Tomcat bins it during its test on return). I've coded in a simple '3 strikes' loop so that I have three chances to retrieve a working connection. I put this live on Sunday evening and will let it run for another day or two before I let you know if this has nay positive impact. After I re-read the full thread I realised that my comment about looking at the bug was arrogant. The problem is clearly more complex than I first thought so I probably won't be looking at it. A question for MySQL - is there any way to disable this internal connection caching, thus avoiding the problem all together? Yes it'll mean less efficiency, but as I'm using the Tomcat connection pool anyway the additional cost will be minimal.
[10 Jan 2006 14:05]
Mark Matthews
The JDBC driver doesn't cache connections, so that's not your problem. Is there a network between your application server and your database, or are both components located on the same machine? Is MySQL restarting because it's crashing, and you're just not noticing?
[10 Jan 2006 15:15]
Phil Haigh
Mark, My mysql server is on a separate machine. As it's all being run by my hosting company I don't actually have access to the machine to check logs etc. Is there a way of seeing the mysql uptime from the mysql command line?
[11 Feb 2006 0:00]
Bugs System
No feedback was provided for this bug for over a month, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open".
[22 Oct 2007 6:26]
ashok patek
To solve this problem change the Mysql connect_timeout variable to it's max limit
[30 Oct 2008 13:35]
Mahabaleshwara Hegde
Hi, I am using MySQL 5.0.x on Debian and Red Hat both, I am getting same exceptions. I changed mySql connection_timeout variable from 5 sec to 60 sec, Still I am getting the same error. should I upgrade the Driver? If yes from where should I download?
[29 Jan 2011 8:50]
Amarjyothi T K
I was getting this exception after deploying my application in the server..
Eg:If my application tries to do a data base transaction .First will get this Exception .If I try it again at that moment itself ,the transaction will happen successfully.After a lot of investigation and work around our Team resolved this issue as follows.
My data source bean was like
<bean id=”dataSource” destroy-method=”close”>
<property name=”driverClassName”> <value>com.mysql.jdbc.Driver</value> </property>
<property name=”url”> <value>jdbc:mysql://${db.host}:3306/${db.database}?autoReconnect=true</value> </property>
<property name=”username”> <value>${db.username}</value> </property>
<property name=”password”> <value>${db.password}</value> </property>
<property name=”initialSize”> <value>2</value> </property>
<property name=”maxActive”> <value>25</value> </property>
<property name=”maxIdle”> <value>5</value> </property>
</bean>
The reason I found was this
1)Spring integrated with hibernate will make a particular number of DB connections and puts them in a pool
2)MySQL is having a property named connection time out for each connection
3)when the application tries to makes a database transaction .Spring will provide the connection available in the pool (but will not check whether the connection is still alive or timed out).
4)I was getting this error because my application was trying to make DB transactions with a non live connection.
so we added two more properties to the data source bean
<property name=”validationQuery”> <value>SELECT 1</value> </property>
<property name=”testOnBorrow”> <value>true</value> </property>
now our data source bean became
<property name=”driverClassName”> <value>com.mysql.jdbc.Driver</value> </property>
<property name=”url”> <value>jdbc:mysql://${db.host}:3306/${db.database}?autoReconnect=true</value> </property>
<property name=”validationQuery”> <value>SELECT 1</value> </property>
<property name=”testOnBorrow”> <value>true</value> </property>
<property name=”username”> <value>${db.username}</value> </property>
<property name=”password”> <value>${db.password}</value> </property>
<property name=”initialSize”> <value>2</value> </property>
<property name=”maxActive”> <value>25</value> </property>
<property name=”maxIdle”> <value>5</value> </property>
</bean>
Now spring will validate the connection in the pool with SELECT 1 query before providing the connection to the application.If the connection is a timed out one, spring will borrow a new connection…and thus our team resolved the issue….May this help u…enjoy
[29 Jan 2011 8:51]
Amarjyothi T K
I was getting this exception after deploying my application in the server..
Eg:If my application tries to do a data base transaction .First will get this Exception .If I try it again at that moment itself ,the transaction will happen successfully.After a lot of investigation and work around our Team resolved this issue as follows.
My data source bean was like
<bean id=”dataSource” destroy-method=”close”>
<property name=”driverClassName”> <value>com.mysql.jdbc.Driver</value> </property>
<property name=”url”> <value>jdbc:mysql://${db.host}:3306/${db.database}?autoReconnect=true</value> </property>
<property name=”username”> <value>${db.username}</value> </property>
<property name=”password”> <value>${db.password}</value> </property>
<property name=”initialSize”> <value>2</value> </property>
<property name=”maxActive”> <value>25</value> </property>
<property name=”maxIdle”> <value>5</value> </property>
</bean>
The reason I found was this
1)Spring integrated with hibernate will make a particular number of DB connections and puts them in a pool
2)MySQL is having a property named connection time out for each connection
3)when the application tries to makes a database transaction .Spring will provide the connection available in the pool (but will not check whether the connection is still alive or timed out).
4)I was getting this error because my application was trying to make DB transactions with a non live connection.
so we added two more properties to the data source bean
<property name=”validationQuery”> <value>SELECT 1</value> </property>
<property name=”testOnBorrow”> <value>true</value> </property>
now our data source bean became
<property name=”driverClassName”> <value>com.mysql.jdbc.Driver</value> </property>
<property name=”url”> <value>jdbc:mysql://${db.host}:3306/${db.database}?autoReconnect=true</value> </property>
<property name=”validationQuery”> <value>SELECT 1</value> </property>
<property name=”testOnBorrow”> <value>true</value> </property>
<property name=”username”> <value>${db.username}</value> </property>
<property name=”password”> <value>${db.password}</value> </property>
<property name=”initialSize”> <value>2</value> </property>
<property name=”maxActive”> <value>25</value> </property>
<property name=”maxIdle”> <value>5</value> </property>
</bean>
Now spring will validate the connection in the pool with SELECT 1 query before providing the connection to the application.If the connection is a timed out one, spring will borrow a new connection…and thus our team resolved the issue….May this help u…enjoy
for details visit
http://javacelibate.wordpress.com/2011/01/29/httpwp-mep1dvvx-a/
[3 Feb 2011 17:19]
Valeriy Kravchuk
Does anybody still think there is some bug in Connector/J here that has to be fixed?
[4 Feb 2011 7:10]
Tonci Grgin
Valeriy, this was about using stale connection from the pool. We do not control pools, they are 3rd party implementation and as Amarjyothi noticed, pool's responsible to check for validity of connection being dealt out of it. So, using validation query (select 1) should do the trick. The rest is addressed by Mark (using stale connection due to automatic reconnect).
[4 Mar 2011 0:00]
Bugs System
No feedback was provided for this bug for over a month, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open".
[29 Apr 2015 14:00]
Alexander Soklakov
Closed as Can't repeat because it's too old, not relevant to current codebase.
Description: I'm using the example 5.1 code for "example of a transaction with retry logic". It's been working for quite some time until I tested 3.1.5-gamma. Now I get this: DBHelper.ensureOpenConnection() retryCount:4 DBHelper.ensureOpenConnection() retryCount:3 DBHelper.ensureOpenConnection() retryCount:2 DBHelper.ensureOpenConnection() retryCount:1 DBHelper.ensureOpenConnection() retryCount:0 com.mysql.jdbc.CommunicationsException: Communications link failure due to under lying exception: ** BEGIN NESTED EXCEPTION ** java.net.SocketException MESSAGE: Broken pipe STACKTRACE: java.net.SocketException: Broken pipe at java.net.SocketOutputStream.socketWrite0(Native Method) at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92) at java.net.SocketOutputStream.write(SocketOutputStream.java:136) at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65) at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123) at com.mysql.jdbc.MysqlIO.send(MysqlIO.java:2618) at com.mysql.jdbc.MysqlIO.send(MysqlIO.java:2549) at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1515) at com.mysql.jdbc.ServerPreparedStatement.serverExecute(ServerPreparedStatement.java:1344) at com.mysql.jdbc.ServerPreparedStatement.executeInternal(ServerPreparedStatement.java:957) at com.mysql.jdbc.PreparedStatement.execute(PreparedStatement.java:1448) at com.wss.calendar.server.DBHelper.ensureOpenConnection(DBHelper.java:203) How to repeat: I think this happens around the 8-hr timeout. Suggested fix: no idea. I upgraded to MySQL mysql Ver 14.7 Distrib 4.1.7, for pc-linux (i686) using the MySQL provided RPMs. Perhaps back out to the GA driver, but I've never been able to use the GA driver in production because of GA bugs. Will test some more ...