On Jan 3, 2013, at 9:58 PM, Suat Gönül wrote: > Hello everyone, > > I have a basic question: Is the execution of log4j blocking or nonblocking? > Assume that I have the following code snippet logging a large string: > > ... > Logger logger = Logger.getLogger(SomeClass.class); > String s = <string containing 500000 characters>; > logger.info(s); > ... > > Is the logging operation delegated to another thread so that the caller > thread continues to execute in a nonblocking way? Or is it blocking i.e the > actual thread waits for the completion of logging operation. > > After seeing the *AsynchAppender, *I guess th**e logging operation is > blocking in default case. And I would like a nonblocking loggin as > described, so should I investigate AsynchAppender? I don't have much > insight about the details of the log4j framework. Sorry if my questions are > silly.
Every logging framework I am aware of is "blocking" (in the sense you are using the term). However, the amount of overhead incurred by the framework is usually so minuscule compared to the application it runs in that it doesn't matter. However, where there is overhead it is typically focused in the Appenders, as they typically do some sort of I/O, which is orders of magnitude slower than all the other processing the frameworks do. The AsynchAppender is one way of moving the Appender overhead to another thread. However, there is nothing stopping anyone from creating a specialized Appender that uses ThreadPools or other ways of minimizing the application overhead. Of course, every choice you make comes with tradeoffs. For example, using an asynchronous approach will mean some loss of reliability. It would be better to understand just what your needs are before making any recommendations. Ralph --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
