RollingSizeTest now seems to be working properly. Ralph
> On Jan 24, 2017, at 6:51 PM, Apache <ralph.go...@dslextreme.com> wrote: > > Actually, in looking at the code I see that there is already a semaphore > there. It is just being improperly released by the rollover method. > > Ralph > >> On Jan 24, 2017, at 6:31 PM, Apache <ralph.go...@dslextreme.com >> <mailto:ralph.go...@dslextreme.com>> wrote: >> >> I thought of that but it doesn’t help. The renames are synchronous and they >> happen with each rollover and conflict with the compression. We have to >> prevent the next rollover from starting before the async task finishes. >> >> Ralph >> >>> On Jan 24, 2017, at 2:55 PM, Matt Sicker <boa...@gmail.com >>> <mailto:boa...@gmail.com>> wrote: >>> >>> 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 >>> <mailto: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 >>> > <mailto: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 >>> > <mailto:log4j-dev-unsubscr...@logging.apache.org> >>> > For additional commands, e-mail: log4j-dev-h...@logging.apache.org >>> > <mailto:log4j-dev-h...@logging.apache.org> >>> > >>> > >>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org >>> <mailto:log4j-dev-unsubscr...@logging.apache.org> >>> For additional commands, e-mail: log4j-dev-h...@logging.apache.org >>> <mailto:log4j-dev-h...@logging.apache.org> >>> >>> >>> >>> >>> -- >>> Matt Sicker <boa...@gmail.com <mailto:boa...@gmail.com>> >> >
