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@qos.ch ReportedBy: Michael_Mansell@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.