You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@logging.apache.org by "Gary D. Gregory (Jira)" <ji...@apache.org> on 2022/01/16 17:16:00 UTC

[jira] [Commented] (LOG4J2-3199) Log4j2 - Strange behavior with Async Logger + JDBC Appender + Oracle DB

    [ https://issues.apache.org/jira/browse/LOG4J2-3199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17476838#comment-17476838 ] 

Gary D. Gregory commented on LOG4J2-3199:
-----------------------------------------

Hi [~jacob2221] 

Can you try this with 2.17.1?

TY.

> Log4j2 - Strange behavior with Async Logger + JDBC Appender + Oracle DB
> -----------------------------------------------------------------------
>
>                 Key: LOG4J2-3199
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-3199
>             Project: Log4j 2
>          Issue Type: Question
>    Affects Versions: 2.9.1
>            Reporter: Jacob Thomas
>            Priority: Minor
>
> Hi,
> Below is the tech stack being used - 
> Log4j2 - 2.9.1
> Spring MVC - 4.2.8.RELEASE
> Oracle JDK - 1.8
> Weblogic - 12.2
> Oracle RDBMS - 19c
> We have a Spring MVC web application deployed on weblogic 12.2 connecting to Oracle 19c via weblogic connection pooling. The application is using Async logger with JDBC Appender having configuration similar to below - 
> _<JDBC name="app-api-db" tableName="API_AUDIT_LOG">_
>             _<DataSource jndiName="appdb"></DataSource>_
>             _<Column name="MESSAGE_ID" pattern="%X\{uniqueId}" />_
>             _<Column name="API_ID" pattern="%X\{apiId}" />_
>             _<Column name="MESSAGE_TYPE" pattern="%X\{msgType}" />_
>             _<Column name="REQUEST" pattern="%X\{reqMsg}" isClob="true" />_
>             _<Column name="RESPONSE" pattern="%X\{resMsg}" isClob="true" />_
>             _<Column name="STATUS_CODE" pattern="%X\{statusCd}" />_
>             _<Column name="STATUS_MSG" pattern="%X\{statusMsg}" />_
>             _<Column name="LOG_TIMESTAMP" isEventTimestamp="true" />_
> _</JDBC>_
> _<AsyncLogger name="com.logger.ApiAuditLogger" level="debug" additivity="false" >_
>             _<AppenderRef ref="app-api-db" />_
> _</AsyncLogger>_
>  
> It is observed that when log4j2 JDBC appender uses the same connection pool as the web application ("appdb"), then we can see multiple DB sessions (v$session & v$sql) executing the "INSERT INTO API_AUDIT_LOG......" sql. 
> But when we create and use a new connection pool exclusively for "log4j" (separate from the one used by web application), there is always only one DB session which is executing the "INSERT INTO API_AUDIT_LOG......" sql. This is irrespective of the number of connections in the pool.
> As in the second scenario, there is only one connection executing the INSERT statement and there are 2 CLOB columns involved, usage of Oracle DB TEMP space used by this DB session keeps on increasing till it uses up all the available TEMP space. However in the first scenario where log4j2 is sharing connection pool with application, there always seem to be multiple DB sessions issuing the INSERT sql and hence the TEMP space usage is much more controlled.
>  
> Could you please help advise why this may be happening? Based on this is it safe to conclude that log4j2 should not be using a separate connection pool of its own; rather it should always use the same pool as the main app?
> Given this behavior, can this issue of TEMP space exhaustion happen even in case both app and log4j2 use the same pool? For eg: Say there is a substantial increase in incoming requests to app but the connection pool is not increased accordingly. Then there could be cases where the same sessions are used by log4j2 more often than before to run INSERT statement because of increased load.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)