[logback-dev] [Bug 135] New: FixedWindowRollingPolicy MAX_WINDOW_SIZE too small?

[bugzilla-daemon at pixie.qos.ch]

http://bugzilla.qos.ch/show_bug.cgi?id=135

           Summary: FixedWindowRollingPolicy MAX_WINDOW_SIZE too small?
           Product: logback-core
           Version: unspecified
          Platform: All
        OS/Version: Windows
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: Rolling
        AssignedTo: logback-dev at qos.ch
        ReportedBy: Michael_Mansell at yahoo.com


I know it's not a blog but let me first say I've switched from log time use of
JCL / log4j and think SLF4J / Logback is awesome so kudos to you guys for
getting this out here... simple and powerful.. not much to not like ;-)

I'm curious as to why a window size as small as 12 was chosen here.  I realize
the renaming of all files within the window gets more expensive as the window
increases but it seems prohibitive for people with larger logging requirements.
 Moreover, the fact that it is final means I can't override this either
although I realize it is rather trivial to build my own implementation.

I have a project that generates a tremendous amount of logging currently (about
100MB every 6 minutes) and in my current setup have issues with files over 2GB.
 With the current MAX_WINDOW_SIZE I can only keep a days worth of logs!

If the rename is a big deal a rolling policy that just uses the index as a
cyclic sequence should work fine or are there other reasons to cap this at
something so low?

I could submit an implementation back if you like but just curious to get your
feedback and any reasoning I might be missing on keeping the window size so
low.

Thanks again for a great product!


-- 
Configure bugmail: http://bugzilla.qos.ch/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.