significant c3p0 error or non-significant c3p0 debug output

yarrow · **Joined:** Fri Dec 28, 2007 11:57 am **Posts:** 5

Hello Hibernate and c3p0 users

I searched everywhere and only found one non-definitive
link about the following debug output:

02:49:21,102 DEBUG NewPooledConnection:566 - com.mchange.v2.c3p0.impl.NewPooledConnection@9c5167 closed by a client.
java.lang.Exception: DEBUG -- CLOSE BY CLIENT STACK TRACE
at com.mchange.v2.c3p0.impl.NewPooledConnection.close(NewPooledConnection.java:566)
at com.mchange.v2.c3p0.impl.NewPooledConnection.close(NewPooledConnection.java:234)
at com.mchange.v2.c3p0.impl.C3P0PooledConnectionPool$1PooledConnectionResourcePoolManager.destroyResource(C3P0PooledConnectionPool.java:470)
at com.mchange.v2.resourcepool.BasicResourcePool$1DestroyResourceTask.run(BasicResourcePool.java:964)
at com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread.run(ThreadPoolAsynchronousRunner.java:547)

I am using Hibenate 3.2 and c3p0-0.9.1.2.

THE QUESTION: Is this significant or can this be ignored ?
(i.e.: is connection pooling working properly ?)

Thanks
Maurice Yarrow

Note:
Am using a basic c3p0 config in hibernate.cfg.xml:
<property name="c3p0.acquire_increment">1</property>
<property name="c3p0.min_size">5</property>
<property name="c3p0.max_size">20</property>
<property name="c3p0.timeout">300</property>
<property name="c3p0.max_statements">50</property>
<property name="c3p0.idle_test_period">3000</property>

<property name="transaction.factory_class">org.hibernate.transaction.JDBCTransactionFactory</property>

gonzao_diaz · **Joined:** Mon Nov 26, 2007 2:29 pm **Posts:** 443

I am also interested in this question.
Please someone respond what kind of messages from c3p0 can be safely ignored.
I'll contribute my credits, too.

yarrow · **Joined:** Fri Dec 28, 2007 11:57 am **Posts:** 5

Hello Gonzalo and hibernate community:

If indeed it is the case that these messages are debug only
but do not indicate that pooling is not working, then the
issue becomes one of:

How to turn them off (evidently:
"Logging-related parameters may be placed in your c3p0.properties file,
in a file called mchange-log.properties" and
"com.mchange.v2.log.FallbackMLog.DEFAULT_CUTOFF_LEVEL" may
be set to suppress these debug messages, according to the c3p0
documentation)

or:

How can I recompile c3p0 source (I tried under jdk1.6 but got
errors) so that this particular message is suppressed, as I did
find this message in the c3p0 source code.

Right now I am using apache dbcp for the pooling, because the
c3p0 DEBUG messages cast doubt on the integrity of c3p0's
pooling.

Maurice Yarrow

gonzao_diaz · **Joined:** Mon Nov 26, 2007 2:29 pm **Posts:** 443

Apparently, the reason and relevance of that java.lang.Exception: DEBUG -- CLOSE BY CLIENT STACK TRACE message is some sort of State secret ...

The Hibernate team advocated adopting c3p0 very vehemently, but it is not doing a good job explaining why this message occurs all the time, or proposing an alternative.

One of the team members is called the "c3p0 guy". You might try sending a private message to him, I don't know.

yarrow · **Joined:** Fri Dec 28, 2007 11:57 am **Posts:** 5

Hello Gonzalo (and Hibernate community)

Point well taken !

I will be glad to send my original message as a new post
to the "c3p0 guy", under subject "Dear c3p0 guy - DEBUG -- CLOSE BY ..."

Let's see what happens...

Maurice

tim_wonil · **Posted:** Thu Jan 24, 2008 12:34 am

I had the same situation, and did some search, and found that it's actually ok to ignore the stack trace.
if you are interested, take a look at the source code:
http://sourceforge.krugle.com/files/arc ... ction.java
specifically:

Code:

    /*
     *  If a throwable cause is provided, the PooledConnection is known to be broken (cause is an invalidating exception)
     *  and this method will not throw any exceptions, even if some resource closes fail.
     *
     *  If cause is null, then we think the PooledConnection is healthy, and we will report (throw) an exception
     *  if resources unexpectedlay fail to close.
     */
    private void close( Throwable cause ) throws SQLException
    {
    [... code removed ...]
        if ( cause == null )
            {
            this.invalidatingException = NORMAL_CLOSE_PLACEHOLDER;

            if ( logger.isLoggable( MLevel.FINEST ) )
                logger.log( MLevel.FINEST, this + " closed by a client.", new Exception("DEBUG -- CLOSE BY CLIENT STACK TRACE") );

IMHO, it seems like a kind of safety mechanism by design to print the stack trace when the log level is at the finest (<= DEBUG) so that it can trace out the the client which closed the connection. To me, it's a little annoying while developing, but once in production, this shouldn't be an issue.