Skip to content

Archive for

Where Am I?

Yes, it’s been 3 weeks since I graduated with my MBA from Georgia State University and I have not blogged since that fantastic day. The reality is, not much has changed. I’m working a few opportunities on a few different fronts but nothing earth shattering.
However today I got this great fortune with my beef and veggies. I usually pack a ham & turkey sandwich for lunch so I know that this was part of destiny. It reads: “Tomorrow your creative side will shine forth with exceptional ideas.”
So with that in mind, I’m going to cut it short today. I don’t want to waste any more energy on these non-exceptional ideas now that I know what tomorrow will bring!

Parents: Use Your Head

I guess this is a case of good research, poor findings. Why do shopping carts, escalators and lawn mowers need to be redesigned when these problems could be minimized by parents teaching their kids to behave and act properly around these and other objects?

Many of the 2,000 annual injuries on escalators occur when a shoe, clothing or a stroller becomes trapped in the space between the moving stairs and the side wall.
Reducing that gap would help, as would having caregivers remove children from strollers before taking an escalator, the report said.

I cannot think of a single escalator that did not have a prominent sign saying “No strollers”. Heck – the strollers probably say ‘Stay off escalators” in their instruction manuals.

Some children got injured when they were trapped in carts, or fell off while riding on the outside or while standing up inside the basket, the report published in the academy’s journal, Pediatrics, said.
The group urged doctors to support changes in cart designs. Meanwhile, parents ought to consider using strollers or wagons, shopping online from home or encouraging children to walk when they are old enough to do so.

More common sense here – sit down in the buggy. If you are too big to sit, then you need to walk on your own. But by all means parents – if you are this ignorant, please take their advice of staying home to shop. Stay home in general. Don’t go outside. A meteor may drop out of the sky and injure you or your child.
Read more of the insanity ->> Parents: beware of shopping carts and escalators – Yahoo! News 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”