[ https://issues.apache.org/jira/browse/LOG4J2-3447 ]


    Pooja Pandey deleted comment on LOG4J2-3447:
    --------------------------------------

was (Author: JIRAUSER285751):
Hello [~pkarwasz],

Adding synchronization to appender methods could NOT fix the issue instead just 
adding synchronized to below method fixing the issue.

class CustomLogger extends Logger {
    protected CustomLogger(String name)

{         super(name);     }

    {color:#ff0000}synchronized {color}public static void LogError(String s, 
Object o)

{           CustomLogger myLogger = getMyLogger();       // If logging not 
enabled for specified type, return without logging the message.       if ( 
!myLogger.isErrorEnabled() )         return;       
myLogger.error("LogMessage");     }

}

> Log4j 1.x 2.17.2 bridge - Synchronization issue in multithreading (Losing 
> huge data in multithreading)
> ------------------------------------------------------------------------------------------------------
>
>                 Key: LOG4J2-3447
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-3447
>             Project: Log4j 2
>          Issue Type: Bug
>          Components: Log4j 1.2 bridge
>    Affects Versions: 2.17.2
>            Reporter: Pooja Pandey
>            Assignee: Piotr Karwasz
>            Priority: Major
>             Fix For: 2.17.3
>
>         Attachments: JavaLoggingMultiThTest.txt
>
>
> In our application we have migrated from log4j1.x to log4j1.x 2.17.2 bridge. 
> With Log4j1.x there was no issue with multithreading but with log4j 1.x 
> bridge we have noticed that in multithreading environment there is a huge 
> data loss while logging, however single thread works fine. I see that in 
> Category.java which Logger extends; many methods are not synchronized any 
> more in log4j1.x bridge however which were synchronized in case of log4j1.x. 
> I suspect this could be root causes of this multithreading problem.
> So as per my understanding synchronized class Category.java in the log4j1.x 
> has become unsynchronized in log4j1.x 2.17.2 bridge. I am not sure if I am 
> missing something.
> We wanted to know how to achieve successful multithreading logging using 
> log4j 1.x 2.17.2 bridge.
> For reference, few methods which were synchronized earlier in log4j1.x but 
> not anymore in log4j1.x bridge.
>  # public void addAppender(final Appender appender)
>  # public Appender getAppender(final String name)
>  # public void removeAppender(final Appender appender)
>  # public void removeAllAppenders()
>  # In log4j 1.x bridge following method is used for logging which doesn't 
> look like synchronized. -> void maybeLog(final String fqcn, final 
> org.apache.logging.log4j.Level level, final Object message, final Throwable 
> throwable); However in log4j1.x following method was used which looks like 
> synchronized. -> void forcedLog(String fqcn, Priority level, Object message, 
> Throwable t) -> void callAppenders(LoggingEvent event), where method void 
> callAppenders(LoggingEvent event) looks snychronized.
>  
> I am attaching sample test program as well which I have used to test 
> multithreading logging in my application. (Please Note that in this test 
> program, class CustomLogger is a dummy class, which you would need to replace 
> with your logger). We are using Custom Rolling Appender in our application 
> and following is the content of log4j properties file. 
> [^JavaLoggingMultiThTest.txt]
> #Custom Rolling Appender
> log4j.appender.R=test.CustomMultiProcessRollingAppender
> log4j.appender.R.File=${user.home}/log4j-multithreading-test.log
> log4j.appender.R.RollOverOnStartup=true
> log4j.appender.R.RollOverOnSize=false
> log4j.appender.R.RollOverMaxFileSize=100MB
> log4j.appender.R.RollOverMaxBackupIndex=10
> log4j.appender.R.RollOverOnPeriodic=false
> log4j.appender.R.RollOverPeriodicStartDate=
> log4j.appender.R.RollOverPeriodicFrequency=1
> log4j.appender.R.layout=org.apache.log4j.PatternLayout
> log4j.appender.R.layout.ConversionPattern=%d %-8M [%t] - %m%n



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

Reply via email to