(oops, re-posting with some white space) Hello, I’m trying to use logback for a distributed application thatI’m working on. I have a custom appender that buffers log messages and thensends them over to a central logger via RMI. The central logger collects thelogs and outputs them to a logback logger that uses a RollingFileAppender witha FixedWindowRollingPolicy and a SizeBasedTriggeringPolicy.
The problem is when the log file hits the size limit insteadof renaming the file and starting a new one it creates 10 (or whatever the maxindex is for the window) copies of the same file and slows down while failingto properly roll over. This results in (after the first rollover trigger) 1 + max index copies of the same file all of which are over the size limit. This issue does not occur when using the same logback configuration file on a single jvm setup. I’ve tried the following: - Did away with the custom appender on the clientsside and just transmitted raw messages over RMI (i.e. only one central Logback loggeris used). Did not resolve the issue. - Switched to a TimeBasedRollingPolicy, under this policy the archiving seems to work properly but the rollover never occurs (the original log file keeps growing). - Switched the central logger over to log4j, this fixed the issue, although I would rather use logback instead. Any ideas about what could be causing this? Thanks, Omar ---------------------------------------- > From: [email protected] > To: [email protected] > Date: Fri, 23 Jul 2010 17:36:22 +0000 > Subject: [logback-user] RollingFileAppender Issues > > > Hello,I’m trying to use logback for a distributed application that I’m > working on. I have a custom appender that buffers log messages and then sends > them over to a central logger via RMI. The central logger collects the logs > and outputs them to a logback logger that uses a RollingFileAppender with a > FixedWindowRollingPolicy and a SizeBasedTriggeringPolicy. The problem is when > the log file hits the size limit instead of renaming the file and starting a > new one it creates 10 (or whatever the max index is for the window) copies of > the same file and slows down while failing to properly roll over. This > results in (after the first rollover trigger) 1 + max index copies of the > same file all of which are over the size limit. This issue does not occur > when using the same logback configuration file on a single jvm setup. I’ve > tried the following:- Did away with the custom appender on the clients side > and just transmitted raw messages over RMI (i.e. only one central Logback > logger is used). Did not resolve the issue.- Switched to a > TimeBasedRollingPolicy, under this policy the archiving seems to work > properly but the rollover never occurs (the original log file keeps > growing).- Switched the central logger over to log4j, this fixed the issue, > although I would rather use logback instead.Any ideas about what could be > causing this?Thanks,Omar > _________________________________________________________________ > http://clk.atdmt.com/UKM/go/197222280/direct/01/ > We want to hear all your funny, exciting and crazy Hotmail stories. Tell us > now > _______________________________________________ > Logback-user mailing list > [email protected] > http://qos.ch/mailman/listinfo/logback-user _________________________________________________________________ http://clk.atdmt.com/UKM/go/197222280/direct/01/ Do you have a story that started on Hotmail? Tell us now _______________________________________________ Logback-user mailing list [email protected] http://qos.ch/mailman/listinfo/logback-user
