Log4j 2
  1. Log4j 2
  2. LOG4J2-457

JDBCAppender does not release JDBC connections to the connection pool when WAR/EAR is stopped

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0-beta9
    • Fix Version/s: 2.0-rc1
    • Component/s: Appenders
    • Labels:
      None
    • Environment:

      JBOSS application server, PostgreSQL database

      Description

      We use log4j 2 for logging inside our J2EE app (packaged as EAR, log4j JARs are bundled inside). The app is deployed on JBOSS EAP 6.1 app server. We are using the JDBCAppender for logging to a PostgreSQL database, and the appender is configured to use a DataSource for fetching connections. The appender is configured as follows:

      <JDBC name="jdbcAppender" tableName="log_entries">
      <DataSource jndiName="java:jboss/datasources/XyzDS" />
      <Column name="log_entries_message" isUnicode="false" pattern="%message" />
      <Column name="log_entries_type" literal="0" />
      .....

      The problem is: after the EAR is stopped (undeployed) log4j is not releasing the JDBC connection back to the connection pool, and after we stop/start the application a couple of times, our server becomes useless because there are no more free connections in the connection pool. I've looked at the thread dump of the server and there are a lot of threads like this:
      org.apache.logging.log4j.core.LoggerContext$ShutdownThread @ 0xbe447138

        Issue Links

          Activity

          Hide
          Nick Williams added a comment -

          Fixed with r1565858 and r1565878. The database appenders now connect to the database (i.e., borrow from the connection pool) and begin a transaction on every flush or every non-buffered writeInternal, then commit and disconnect (i.e., return to pool) at the end of the flush or non-buffered writeInternal.

          Note also that the <DriverManager...> connection source plugin is no longer available. It was removed because it was unsafe and didn't support connection pooling. Please use the <DataSource...> or <ConnectionFactory...> connection source plugins, instead.

          Show
          Nick Williams added a comment - Fixed with r1565858 and r1565878. The database appenders now connect to the database (i.e., borrow from the connection pool) and begin a transaction on every flush or every non-buffered writeInternal , then commit and disconnect (i.e., return to pool) at the end of the flush or non-buffered writeInternal . Note also that the <DriverManager...> connection source plugin is no longer available. It was removed because it was unsafe and didn't support connection pooling. Please use the <DataSource...> or <ConnectionFactory...> connection source plugins, instead.
          Hide
          Matt Sicker added a comment -

          Well that's super convenient! I'll have to look into that sometime.

          Show
          Matt Sicker added a comment - Well that's super convenient! I'll have to look into that sometime.
          Hide
          Gary Gregory added a comment -

          Commons DBCP 2 is around the corner FYI.

          Show
          Gary Gregory added a comment - Commons DBCP 2 is around the corner FYI.
          Hide
          Matt Sicker added a comment -

          In general, the JDBC appender classes need to use a more robust method to managing connections. It's annoying to use with DriverManager, for instance, since we'd have to do manual connection pooling which is rather error prone. Using DataSource or JNDI both give you the connection pooling for free practically, but DriverManager is pretty low level.

          Show
          Matt Sicker added a comment - In general, the JDBC appender classes need to use a more robust method to managing connections. It's annoying to use with DriverManager, for instance, since we'd have to do manual connection pooling which is rather error prone. Using DataSource or JNDI both give you the connection pooling for free practically, but DriverManager is pretty low level.

            People

            • Assignee:
              Nick Williams
              Reporter:
              Tihomir Meščić
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development