Inlines again and sorry for the previous empty message. I hit the send button before I actually wrote something. ;-)
2013/8/13 d_k <mail...@gmail.com> > Inlined. > > On Mon, Aug 12, 2013 at 11:06 AM, Stefan Bodewig <bode...@apache.org>wrote: > >> [just changing the subject :-)] >> >> On 2013-08-12, Dominik Psenner wrote: >> >> > Another issue that I just remembered now is that currently there's no >> way to >> > roll empty files on date/time boundaries. Rolling only happens when a >> log >> > event is generated. If there's no log event, files won't be rolled. >> Thus we >> > should investigate if we should implement the appender as a buffering >> async >> > appender that does the rolling in his async work cycles and whose work >> > cycles do not depend on the availability of log events. >> > > Making the appender async is a major change and it has ramifications that > might prove problematic like unflushed buffers. > And if we make the buffer of size 1 then its really synchronous again, > isn't it? > > Does a 'roll' create a new file? > That would depend on what rolling strategy is used. One might want to send emails whenever a logfile is not empty. > So if there are no log event the folder will be polluted with empty files? > If a 'roll' does not create a file then we can make the decision to roll > or not as part of the logging process. > > If it is configured to do so, yes, it pollutes the file system with empty files. > >> >> I'm up for a clean way to roll but I think that a logging framework that > creates files other than logs is odd. And adding a dependency on some > persistent storage provider is also odd. > .. you've gotta stick what you've got. > I think we can assume that applications that need to perform rolling on > size or date are probably long running which means we can save this > information in memory and in case the application crashed or restarts then > yes, the old files will remain on disk and it should be solved by a local > policy because it the exception, not the rule. > You're wrong. Rolling is mainly there to limit the possible quota logfiles can use. >> I think that an XML hierarchy will be easier to parse than strings > containing conditions. > Something like: > > <rollOn><date hours='3' /></rollOn> > <dispose><files filenumber='50' /></dispose> > And we can provide some custom data to be passed back to a custom rolling > strategy as a string and the you can parse it the way you want in the > strategy you've written. > We're not stupid enough to invent something unparseable .. ;-)
