Hi Ralph, Thanks a lot for your answer.
Actually, I would like a nonblocking logging for server side of a client-server architecture. In the server side, we will usually perform lightweight operations based on requests coming from clients and do lots of logging for these operations. And we cannot tolerate server response times longer than half of a second (approximately). I thought lots of logging operations may take some time in a multiclient environment (10000s of clients), since it is an I/O bound operation. So, I thought it would be more appropriate to delegate logging operation to a separate thread, since it does not matter when the log is persisted to the file as long as I provide the timestamp indicating the actual time regarding that log. I think the most reliable way to try both solutions (i.e blocking or nonblocking) and compare the results. Thanks again for your suggestions. Best, Suat On Fri, Jan 4, 2013 at 9:27 AM, Ralph Goers <[email protected]>wrote: > > 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: [email protected] > For additional commands, e-mail: [email protected] > >
