Version 6

    Debug Connection Problems


    A quick overview of what to look at for connection problems. This page should just be a link

    to other wiki pages where the information is dealt with in more detail.


    Many others can be found in the FAQ or main page.


    Not closing connections


    For EJBs and Servlets JBoss can tell you and note this wasn't enabled by default in older versions of JBoss for servlets.


    The CachedConnectionManager has a


    for other environments.


    You should always close connections in finally blocks


    Connection c = dataSoruce.getConnection();
    // Don't put anything here that could throw an exception (e.g. c.setAutoCommit(false))
       // Do stuff here!
       // Always close the connection


    Transaction leaks could also be a problem if the

    transaction is not committed. These are also detected in EJBs and Servlets (again not enabled by default for servlets in older versions).


    Waiting too long


    If your pool is exhausted then it will wait blocking-timeout-millis before it will throw an Exception


    Stuck in the backend


    If your running into pool exhaustion then the problem could also be on the backend (database server, jms server, etc.) with requests not returning. Thread dumps will help you see what the threads are doing. Make sure you have done whatever configuration is required by the backend

    server and its "client side" driver (e.g. jdbc driver) to detect network splits.


    For the new transaction manager in JBoss-4.2, transaction timeouts will automatically rollback the transaction and release the connections, in the old transaction manager, the only mechanism was to interrupt the thread to break out of the I/O. This was disabled by default in JBoss4.


    You should also look at what the backend provides in terms of logs and debugging the adapters, e.g. the jdbc drivers.


    Pool statistics


    The JMX MBean for the pool has many statistics. Here's an example on how to enable monitoring to a log.




    The forums READ THIS FIRST explains how to enable TRACE logging. With this enabled, you can see what is happening to every connection and what transactions/threads they are talking part in.


    There's also some simple pooling stats displayed at every checkout/checking, but don't get confused by the


    count. This is the number of connections that could possibly be checked out from the pool, it is not necessarily how many connections really exist. The pool will create the connections if they are really required.