The really correct way that this should be handled is for the test to look at all the compressed files and wait until the uncompressed file it is created from no longer exists. When that happens you can be sure the compressed file should be good.
Ralph > On Jul 4, 2016, at 9:22 AM, Gary Gregory <[email protected]> wrote: > > Wait a sec, if the problem is that a log4j thread is not done doing > compression, then log4j is not completely shut down. The clean up code > expects log4j to be done. Either the logger context rule is not shutting down > log4j correctly or log4j is not doing all it needs to do to shutdown. > > Maybe we need a new shutdown-all API that might take a time out. Hm, the > logger context rule works on a context so it's the context that might need > improvement. > > Do we use a thread pool to host all our threads? That would be an easy way to > shutdown threads. > > Thoughts? > > Happy 4th to US folks! > > Gary > > On Jul 4, 2016 6:41 AM, "Ralph Goers" <[email protected] > <mailto:[email protected]>> wrote: > This is a bug in CleanFolders. If it encounters an error deleting files it > retries deleting the directory up to 9 more times. However, it still fails > because it failed the first time even if the delete subsequently worked. I > have a fix for this. > > I have a suspicion that the bzip test is failing because it is trying to > decompress a file that has not finished compressing. I am going to try adding > a sleep for 100 ms to see if that fixes the problem. > > Ralph > >> On Jul 2, 2016, at 12:14 PM, Matt Sicker <[email protected] >> <mailto:[email protected]>> wrote: >> >> I haven't seen pack200 fail before. Who uses pack200 anyways? >> >> On 2 July 2016 at 08:58, Remko Popma <[email protected] >> <mailto:[email protected]>> wrote: >> Our old friends >> >> Failed Tests >> >> <>org.apache.logging.log4j:log4j-core >> <https://builds.apache.org/job/Log4j%202.x/2082/org.apache.logging.log4j$log4j-core/testReport> >> Test Name >> <https://builds.apache.org/job/Log4j%202.x/2082/testReport/#> Duration >> <https://builds.apache.org/job/Log4j%202.x/2082/testReport/#> Age >> <https://builds.apache.org/job/Log4j%202.x/2082/testReport/#> >> <> >> org.apache.logging.log4j.core.appender.rolling.RollingAppenderSizeTest.testAppender[log4j-rolling-bzip2.xml >> → .bz2] >> <https://builds.apache.org/job/Log4j%202.x/2082/org.apache.logging.log4j$log4j-core/testReport/org.apache.logging.log4j.core.appender.rolling/RollingAppenderSizeTest/testAppender_log4j_rolling_bzip2_xml____bz2_/> >> 0.35 sec 1 >> <> >> org.apache.logging.log4j.core.appender.rolling.RollingAppenderSizeTest.testAppender[log4j-rolling-pack200.xml >> → .pack200] >> <https://builds.apache.org/job/Log4j%202.x/2082/org.apache.logging.log4j$log4j-core/testReport/org.apache.logging.log4j.core.appender.rolling/RollingAppenderSizeTest/testAppender_log4j_rolling_pack200_xml____pack200_/> >> 0.33 sec 1 >> >> On Sat, Jul 2, 2016 at 10:03 PM, Apache Jenkins Server >> <[email protected] <mailto:[email protected]>> wrote: >> See <https://builds.apache.org/job/Log4j%202.x/2082/changes >> <https://builds.apache.org/job/Log4j%202.x/2082/changes>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> <mailto:[email protected]> >> For additional commands, e-mail: [email protected] >> <mailto:[email protected]> >> >> >> >> >> >> -- >> Matt Sicker <[email protected] <mailto:[email protected]>> >
