A custom ExecutorService extension that only allows one task of each kind to be executed at a time or some other classifier could be an approach possibly?
On 24 January 2017 at 15:53, Apache <ralph.go...@dslextreme.com> wrote: > I ended up having to put a delay in the loop that logs events and increase > the number of bytes in each file. Obviously, this isn’t a perfect solution, > but I’m really not sure what we can do if the async task takes longer than > the time it takes to schedule it again. I suppose one option would be to > put in a guard that would prevent a subsequent rollover from occurring > until the async tasks complete. > > Ralph > > > On Jan 24, 2017, at 1:03 PM, Apache <ralph.go...@dslextreme.com> wrote: > > > > I am looking at the failures that are occurring in the > RollingAppenderSizeTest in the Jenkins build. I am working at modifying the > code so that the asynchronous tasks will complete before shutdown is > allowed to complete. But I am running into an issue I am not sure how to > resolve. The test is configured to have the log file roll over after 500 > bytes have been written. It seems that some of the compression algorithms > take longer than it takes to write 500 bytes, so after the maximum number > of files are reached the system is rolling over on top of files that are in > the process of being archived, so we get rename/move and delete problems. > > > > Any ideas? > > > > Ralph > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org > > For additional commands, e-mail: log4j-dev-h...@logging.apache.org > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org > For additional commands, e-mail: log4j-dev-h...@logging.apache.org > > -- Matt Sicker <boa...@gmail.com>
