Thanks Thorsten for the reply. Yes, it is a hard problem. On one side, users would like not to miss any logs after the system comes up; On the other hand, some external syslog servers needs some extra handling to resolve its DNS names for instance (we choose to do dns name conversion ourselves because we experience sporadic non-recoverable dns conversion failure in log4cxx).
How is the log4cxx buffering works exactly? say if you specify a large buffer size, is the first log message sent out after the buffer gets full, or it can be sent any time after it's put into the buffer? Also, is it possible to post log messages to a subset of the appenders in an AsyncAppender? Thanks, On Tue, Jul 29, 2014 at 12:02 AM, Thorsten Schöning <tschoen...@am-soft.de> wrote: > Guten Tag Alder Netw, > am Dienstag, 29. Juli 2014 um 00:44 schrieben Sie: > > > Say, if we create a log4cxx::AsyncAppender(), and add an appender A > > which is ready to it via addAppender() at time t0, and when another > appender > > B is ready and is added to it at a later time t1. Would the > > messages between t0 and t1 be sent to B after it's up? > > That depends on the size of the buffer: If it's small and has already > been sent to all available appenders between t0 and t1, than no, the > contents of the buffer are cleared afterwards. If it is large and can > store all the events occurring between t0 and t1 than yes, B will get > the contents as well, simply because they get send late enough. > > Have a look in asyncappender::dispatch. > > > If not the > > the app needs to buffer them and resend after B is added? The A > > would get duplicated copy? > > Yes. > > > How to handle this in the current log4cxx framework? > > That depends mainly on your appenders, preferrable you should make > sure that they are all available shortly after application start or > such. Everything else seems difficult to me: Resending an already sent > buffer would need you to create your own second buffer to save all > contents for "all times" until appender B gets available. But what if > it doesn't ever for some reason? And what if you ever need some more > appenders C and D and E...? With each appender you would need a larger > buffer to save all events until the appenders are available. > > If you have your second buffer you will need to decide if you only > send that content to the newly available appender B or C or D..., > which should possible by simply getting your newly added appender and > post the messages pre formatted directly to it. If you just log your > second buffer's contents again, it would ge doubled output by all > former existing appenders. If you wouldn't want that you would need to > find a way to distinguish between already sent messages for old > appenders and unseen messages for newly added once and that seems hard > to do. > > Therefore I would try to bring all appenders up as soon as possible, > use a reasonable buffer size to overcome this time and would bother > with everything else. You should even be able to use a larger buffer > size for bringing all your appenders up and reduce that size > afterwards. > > > http://logging.apache.org/log4cxx/apidocs/classlog4cxx_1_1_async_appender.html#ad425c4f62bccf271e87b4669994be47b > > Mit freundlichen Grüßen, > > Thorsten Schöning > > -- > Thorsten Schöning E-Mail:thorsten.schoen...@am-soft.de > AM-SoFT IT-Systeme http://www.AM-SoFT.de/ > > Telefon...........05151- 9468- 55 > Fax...............05151- 9468- 88 > Mobil..............0178-8 9468- 04 > > AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln > AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow > >
