Log4j 2 has a BurstFilter that can be used for throttling. Ralph
> On Mar 7, 2016, at 9:19 AM, Nicholas Duane <nic...@msn.com> wrote: > > I was asking about what's getting logged as I figured we shouldn't have that > much in there to be too worried about disk space consumption. The appender > in question is an https appender we wrote. If it encounters an exception is > calls LOGGER.error(). We should have some throttling around that such that > we don't generate 1-for-1 errors for each exception we encounter since a > problem with the https endpoint could flood the system, but we don't have > that throttling yet. We're redirecting stdout now which is why we're running > into some disk consumption issue. Is there a safe way to implement rolling > the file without the generating app knowing about it? Wouldn't I potentially > be deleting the file contents out from under it? > > I have a related question, does log4j2 have some throttling of its own? If I > removed the LOGGER.error() and just let the exception bubble up to log4j2, > would it throttle those errors? I think I was investigating this earlier and > noticed some throttling but can't be sure. > > ...<some time going by while I'm thinking>... > > I guess we could write our own application which takes stdin and writes to > files and this could do the rolling file work. I would think something like > that might already exist in linux. > > Thanks, > Nick > >> Subject: Re: controlling the status logger output? >> From: ralph.go...@dslextreme.com >> Date: Mon, 7 Mar 2016 08:54:05 -0700 >> To: log4j-user@logging.apache.org >> >> If you set the status level to ERROR the StatusLogger should generate very >> little output. That said, if you are concerned you can redirect stdout and >> implement the rolling yourself. >> >> Ralph >> >>> On Mar 7, 2016, at 8:39 AM, Nicholas Duane <nic...@msn.com> wrote: >>> >>> We've written some appenders and I think the prescribed approach is to use >>> the status logger in log4j2 components, is that correct? The problem we're >>> running into is that we redirect stdout to a file and thus that file can >>> grow unbounded. It seems there's no way to have something like a rolling >>> file appender for the status logger, correct? Any suggestions for limiting >>> the size of the log generated by the status logger when stdout has been >>> redirected to a file? >>> >>> Thanks, >>> Nick >>> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org >> For additional commands, e-mail: log4j-user-h...@logging.apache.org >> > --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
