I think you hit the nail on the head - try both in your prod environment. We were using the default with rolling file appender. 400 files max 4 mb with 120 logs per txn and just 3 TPS max. But some of our hsm , db coupled with logging meant our con pools were exhausted. The day it happened we changed to async as we need the debug logs. Later we did optimize app code too. Trade off is can't kill the java app till we stop sending txns to that node and wait 10 seconds for logs to be written. Which is fine.
On 1/4/13, Suat Gönül <suatgo...@gmail.com> wrote: > 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 > <ralph.go...@dslextreme.com>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: log4j-user-unsubscr...@logging.apache.org >> For additional commands, e-mail: log4j-user-h...@logging.apache.org >> >> > -- Sent from my mobile device Regards Tushar Kapila --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
