Skip to content Broken Pipe Exception

For the last week, I’ve been chasing down a randomly occuring broken pipe exception in the banking app we’ve written. It was like looking for a needle in a haystack.
The Problem
Database connections were being tied up to the length of wait_timeout on the MySQL server. We’re using Hibernate for our persistence layer and C3P0 for our connection pool. During initial pilot testing, we only saw issues after a long period of time. My assumption was that the pool was not doing its job and MySQL was killing the connections. However, after ramping up the testing to a larger scale, the exception began occuring much more often.
Here is the dump I was seeing:

10:01:57,812 WARN NewPooledConnection:356 – [c3p0] A PooledConnection that has already signalled a Connection error is still in use!
10:01:57,813 WARN NewPooledConnection:357 – [c3p0] Another error has occurred [ com.mysql.jdbc.CommunicationsException: Communications link failure due to underlying exception:
MESSAGE: Broken pipe
STACKTRACE: Broken pipe
at Method)
at Code))
at Code))
at Compiled Code))
at Compiled Code))
at com.mysql.jdbc.MysqlIO.send( Code))
at com.mysql.jdbc.MysqlIO.send( Compiled Code))
at com.mysql.jdbc.MysqlIO.sendCommand( Code))
at com.mysql.jdbc.MysqlIO.sqlQueryDirect( Code))
at com.mysql.jdbc.Connection.execSQL( Code))
at com.mysql.jdbc.PreparedStatement.executeInternal(
at com.mysql.jdbc.PreparedStatement.executeQuery(
at com.mchange.v2.c3p0.impl.NewProxyPreparedStatement.executeQuery(
at org.hibernate.jdbc.AbstractBatcher.getResultSet(
at org.hibernate.loader.Loader.getResultSet(
at org.hibernate.loader.Loader.doQuery(
at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(
at org.hibernate.loader.Loader.doList(
at org.hibernate.loader.Loader.listIgnoreQueryCache(
at org.hibernate.loader.Loader.list(
at org.hibernate.loader.hql.QueryLoader.list(
at org.hibernate.hql.ast.QueryTranslatorImpl.list(
at org.hibernate.engine.query.HQLQueryPlan.performList(
at org.hibernate.impl.SessionImpl.list(
at org.hibernate.impl.QueryImpl.list(
at org.hibernate.impl.AbstractQueryImpl.uniqueResult(
at com.bbcs.consumercard.dao.AccountDAO.getAccount(
at com.bbcs.consumercard.actions.account.WebPayRequestAction.doExecute(
at com.bbcs.consumercard.actions.SecureBaseAction.execute(
at org.apache.struts.action.RequestProcessor.processActionPerform(
at org.apache.struts.action.RequestProcessor.process(
at org.apache.struts.action.ActionServlet.process(
at org.apache.struts.action.ActionServlet.doGet(
at javax.servlet.http.HttpServlet.service(
at javax.servlet.http.HttpServlet.service( Code))
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
at org.apache.catalina.core.ApplicationFilterChain.doFilter(
at org.apache.catalina.core.StandardWrapperValve.invoke(
at org.apache.catalina.core.StandardContextValve.invoke(
at org.apache.catalina.core.StandardHostValve.invoke(
at org.apache.catalina.valves.ErrorReportValve.invoke(
at org.apache.catalina.core.StandardEngineValve.invoke(
at org.apache.catalina.connector.CoyoteAdapter.service(
at org.apache.jk.server.JkCoyoteHandler.invoke(
at org.apache.jk.common.HandlerRequest.invoke(
at org.apache.jk.common.ChannelSocket.invoke(
at org.apache.jk.common.ChannelSocket.processConnection(
at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(
at org.apache.tomcat.util.threads.ThreadPool$

Possible Solutions
Initially I thought the problem may lie somewhere in our code, but since this was the first time I used C3P0 for my connection pool I decided to Google the problem first. Many of the postings I found related to failures on the part of the connection pool. Based on this post, I ripped out C3P0 and implemented DBCP. That did not fix my problem, though. Some posts say it is a problem with the driver (I do not believe that it is), others blame the c3p0 connection pool (I do not).
Our Solution
In fact, our problem was sitting in our own code and was implemented by someone who was not seasoned in transactions. When you demarcate transactions, you have to explicity commit or rollback every time. Some newbies believe that queries do not have to be committed. They do. If not, the connection is left assigned in case you wanted to manipulate the resultset or do additional reads (there are other reasons, but these are the easiest to wrap your mind around).
So in our case, a transaction was begun and a query was executed. Unfortunately, the transaction was not committed in every circumstance, leaving dangling connections that later got killed by MySQL. C3P0 would later attempt to reattach to the now defunct dangling connection and kaboom – Broken PIpe would appear. Finding the spot in the code (it was in some complicated if/else logic) and correcting it solved our problem and we have not had a problem with Hibernate or C3P0 since!
Update: 7 August 2006
In the 3 days since I’ve posted this, it has already garnered a lot of page views. I didn’t realize it would be such a hit. For most of you, it should just be a matter of setting up periodic connection testing. Here are some more pointers to information if you are getting this error:
C3P0: Configuring Connection Testing
Hibernate specific properties for C3P0
More Hibernate specific configuration info
Updated 15 February 2007 – fixed link to “Hibernate Specific Properties for C3P0”

18 Comments Post a comment
  1. Binh Thanh Nguyen #

    Thanks, nice tip

    October 6, 2017
  2. zhouchao #

    Thanks! This is very helpful!

    July 17, 2015
  3. Nikhil #

    got to this page after all these years and it is still very helpful. thanks.

    January 9, 2013
  4. lanre #

    After 6 years, it’s still an eye opener. Thanks.

    October 2, 2012
  5. lucius #

    thank you very much, it is helpful for me.

    January 13, 2012
  6. Alfredo Mezquitic #

    I really appreciate your post…!!!.. thx

    November 28, 2008
  7. Julien #

    Thank !

    August 7, 2008
  8. nyjava #

    Thanks a lot

    June 25, 2008
  9. prashant #

    thanks for this Guidence.

    May 7, 2008
  10. Arman #

    Good post. Thanks!

    April 29, 2008
  11. Raja Nagendra Kumar #

    Short cut approach could be use
    <property name=”hibernate.connection.autocommit”>true</property>
    to make the auto commit happen.
    Raja Nagendra Kumar
    Java Code Audit and Refactoring Offshore company

    April 13, 2008
  12. Thank you! Your report helped me very much!!

    November 15, 2007
  13. dinakar #

    Good One!

    October 7, 2007
  14. Thank you very much! Very useful!

    September 29, 2007
  15. Yassin SIbai #

    Thank you for the info. It is very helpful.

    May 17, 2007
  16. Sébastien Christy #

    Thanks for the info, it’s very valuable.
    The “Hibernate specific properties for C3P0” link is broken.
    I think the correct link is :

    February 15, 2007
  17. Ovidiu #

    cool info

    December 15, 2006
  18. Naveen #

    1. reset by peer:
    JVM_recv in socket input stream read.
    2. IOException:Connection reset by peer:socket write error.
    3. IOExcepion:Broken pipe.
    All this exceptions are not thrown at the same time and might not always been thrown.
    These Exceptions are mainly caused due to the resubmission of jsp page twice. By using Input type = ‘submit’ itself submits the page not need to call from java script as form.submit. If we want to use form.submit from java script for Input type as ‘submit’ then you need to disable the submit button after one click.
    The threads running under the server may not be executing synchronously and inappropriate page submissions can cause this exceptions.

    October 11, 2006

Leave a Reply

You may use basic HTML in your comments. Your email address will not be published.

Subscribe to this comment feed via RSS