CLIENT STACK TRACE in Hibernate using c3p0

Question

This may be a duplicate of Weird Error: CLOSE BY CLIENT STACK TRACE But I've asked a new question because I don't see isLoggable method for Log. I'm using Logger class of org.apache.log4j.Logger for my log purpose.

My error is same

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)

My code is

    public JSONObject getUserDetails(int id) {
    System.setProperty("net.sf.ehcache.skipUpdateCheck", "true");
    long lStartTime = new Date().getTime();
    JSONObject obj = new JSONObject();
    try (Session session = factory.openSession()) {
        Employee emp = (Employee) session.load(Employee.class, id);
        if (emp != null) {
            obj.put("id", emp.getId());
            obj.put("name", emp.getName());
        }
        long lEndTime = new Date().getTime();
        log.info("[ Personal Details ]Time elapsed For Fetching :"
                + (lEndTime - lStartTime));

    } catch (Exception e) {
        log.error(e);
    }
    return obj;
}

Edit :

My implentation is :

public class PersonalisationImpl implements PersonalisationDao {
private void close( Throwable cause ) throws SQLException
{ 
    close( cause, false ); 
}

private void close(Throwable cause, boolean b) {
    // TODO Auto-generated method stub
    assert Thread.holdsLock( this );
    if ( logger.isLoggable( MLevel.FINEST ) )
          logger.log( MLevel.FINEST, this + " closed by a client.", 
                    new Exception("DEBUG -- CLOSE BY CLIENT STACK TRACE") );
}

Where should I write the method of isLoggable method in the code and which logger class should I use?

Portaltoportal

Answer 1

you don't write an isLoggable(...) method. that already exists in the logging library and c3p0 calls it.

your problem is that you are logging at TRACE/FINEST levels, which means you are getting a lot of debugging info, including logged stack traces, that you don't want.

you need to figure out how to configure whatever logging library you are using to log only messages at INFO or above for libraries beginning with com.mchange. that's it! configure your logging so that you stop logging debug-level messages, and this will go away. there is no problem. you are just logging too much information.

Fencing

Thanks Steve. Logger for the above scenario is of Java.util package. I've edited the question by putting my implementation and that is not getting called. Please check it. – Portaltoportal

if you are using java.util.logging.*, you'll want to configure logging.properties. if you are using log4j log4j.properties. if logback, then logback.xml. set the default log level to INFO, for everything or at least for loggers beginning with com.mchange. your implementation makes no sense to me. it looks like you've copied c3p0 code into one of your own classes, which you should not do. – Fencing

Initially I've configured with Log4j. But as it doesn't have isLoggable method, I've used Java.util.logging. What exactly I need to do? – Portaltoportal

you don't want to write any code. you are not looking for any method. all you want to do is write a config file that tells your logging library, whichever one you choose, not to log below info. you can see some (bad! unstable!) example config files i use for testing here – Fencing

I want to write code, but I'm not sure what it should have to fix this error. – Portaltoportal

no! you don't want to write code. you might be able to write code to modify constructs in your logging library directly, but that would be a bad idea, render your app unmaintainable and inflexible. logging libraries are designed so that you configure the level of detail of your logs externally. you just mess with a config file, never with the code. whatever logging library you ultimately settle on will want a config file. that's where you set the logging level. make the default level INFO, rather than FINEST or TRACE or DEBUG. then the unnecessary logging will go away. – Fencing

there is no error by the way. c3p0 just logs the stack trace of PooledConnection.close() at TRACE levels, which in the past has proved helpful at chasing now problems where these objects were unexpectedly closed. leaving things as they are is a performance cost (capturing and logging stack traces has significant overhead), but reflects no error and does no harm. still, you should fix it, because logs filled with DEBUG stack traces make it hard to see more serious problems, and you don't want to bear the cost of all those stack trace captures. – Fencing

Just updated to log4j.rootLogger = INFO, X, stdout in my Log4j.properties. Only my INFO are getting now printed in console. – Portaltoportal

good. so you should be seeing much less, and no DEBUG stack traces. – Fencing

correct. and even if still want to fix it, if requires, how can I do that? – Portaltoportal

there is nothing to fix! there is no error! that Exception and stack trace exist solely to be logged at TRACE / FINEST level. nothing went wrong. c3p0 was originally written in jdk 1.3. there was no way to log a stack trace for debugging purposes then without constructing an Exception and asking it to printStackTrace(...) at TRACE level, c3p0 simply logs the stack traces that closes the PooledConnection for debugging purposes. there has been no error or problem to fix. it's just logging extra info that might be helpful for debugging. setting log level to INFO did not hide or mask any problem. – Fencing

when c3p0 actually experienced a problem, it logs at WARN, so you will see it. – Fencing

Thanks Steve. As of now I will just keep as INFO itself. Do you have any idea on min and max connections for a web application? My web app would have 10000-20000 users. How many max connection should be there and on what basis can I calculate? – Portaltoportal

probably lots fewer than you think, no more than 100. see eg github.com/brettwooldridge/HikariCP/wiki/About-Pool-Sizing – Fencing

Thanks Steve..I have already gone through that. According to you which web server is best for such users count? Tomcat web server or nginx server? – Portaltoportal

if your app is a Java Servlet based webapp, you'll need a Servlet container like Tomcat (or Jetty or others) no matter what. Typically, you put that behind nginx, because you have more web services than just your webapp and nginx lets you configure multipler hosts and URIs to different backends. if the only web service running on your machine will be your app (maybe with other Servlet-based webapps), you can just run tomcat directly. but that's less typical. – Fencing

It's a Java servlet based webapp itself. I think then I should even add nginix because I may have multiple jersey restful webservices to be deployed. – Portaltoportal