Some background is in order here; there are several file handle "leaks" that will actually lead to the file handle being closed in a finalizer. Which is why "shaking" System.gc a couple of times with a sleep/retry or two sometimes actually is effective if weird :)
Within shade I just fixed all of these leaks to use deterministic closing of all resources, so nothing gets closed in finalizers any more. To my understanding these calls to System.gc and any kind of retry logic can just be removed. So IMI it's a no-brainer, but sometimes there's more history behind such hacks... Kristian 2015-11-21 11:13 GMT+01:00 Hervé BOUTEMY <herve.bout...@free.fr>: > yes, should be deleted from a plugin silently doing such hacks: if we try to > work around leaks issues, it should at least advertise that a leak was found, > trying to show where the issue is > > Since there is currently no warning, I don't know how much issues will now be > visible if the plugin simply fails on such (recoverable) leaks > > Do you have an idea of how much recoverable such leaks are with the > System.gc() hack? > > Just to choose if the removal should be done in 2 phases (warn before remove). > > Because the only issue I fear is this hack makes the shade plugin have support > for other plugins leaks: it's probably not easy to know how much plugins have > leaks... > > Regards, > > Hervé > > Le samedi 21 novembre 2015 10:16:51 Karl Heinz Marbaise a écrit : >> Hi Kristian, >> >> On 11/21/15 9:33 AM, Kristian Rosenvold wrote: >> > As some of you may have noticed, I have fixed a bunch of file handle leaks >> > in the last weeks. This may eventually make running a CI on windows >> > feasible :) >> > >> > The shade plugin was leaking like a sieve, and should now be fully >> > watertight. There seems to be a few bits of silly code that I'd just like >> > to remove, since the root cause in all likelyhood is fixed: >> > >> > For instance this; >> > >> > https://maven.apache.org/plugins/maven-shade-plugin/xref/org/apache/maven/ >> > plugins/shade/mojo/ShadeMojo.html#L643 >> This is definitively a thing which should be deleted... >> >> > Any objections ? >> >> No.. >> >> > Kristian >> > >> > 5. nov. 2015 5.29 p.m. skrev "Tibor Digana" <tibor.dig...@googlemail.com>: >> >> This issues is caused by long Windows paths. >> >> INFRA made shorter file names and issue disappeared. >> >> Reported issue with Git 2.6.2 installation requirements and Git variable >> >> "core.longPaths=true" setup, see >> >> https://issues.apache.org/jira/browse/INFRA-10724. >> >> >> >> On Fri, Oct 23, 2015 at 6:22 AM, Kristian Rosenvold < >> >> >> >> kristian.rosenv...@gmail.com> wrote: >> >>> (Tibor; I'm taking this to the mailing list) >> >>> >> >>> >> >>> It would appear that we are leaking file handles/resources when being >> >>> killed by jenkins. This is not entirely surprising, since this is >> >>> notoriously hard to get right. Does anyone know how the timeout in >> >>> jenkins kills our process ? (If it's the equivalent of kill -9 we're >> >>> in trouble no matter what, but usually some softer means is used >> >>> first....) >> >>> >> >>> I'll montor for resurce leaks while killing processes this weekend to >> >>> see if I can find anything. >> >>> >> >>> Kristian >> >>> >> >>> >> >>> >> >>> ---------- Forwarded message ---------- >> >>> From: Tibor Digana <tibor.dig...@googlemail.com> >> >>> Date: 2015-10-22 21:05 GMT+02:00 >> >>> Subject: Re: to delete windows build ? >> >>> To: Andreas Gudian <andreas.gud...@gmail.com> >> >>> Kopi: Kristian Rosenvold <kristian.rosenv...@gmail.com> >> >>> >> >>>>> Could it be the ancient shadefire-version that causes hanging >> >>>>> processes >> >>> >> >>> in our integration tests on those windows nodes? >> >>> I do not know since I could not reproduce this issue on my system. >> >>> >> >>> IMHO the files are locked after the job has timed out. My words in JIRA: >> >>> "The build setup says that the build timeout is 69 min. The bild was >> >>> running 64 which is very close." >> >>> >> >>> I should reopen the bug and ask INFRA to clean up the workspace. >> >>> >> >>> I expected INFRA to find out the root cause. The time out issue is a >> >> >> >> guess. >> >> >> >>> Cheers >> >>> Tibor >> >>> >> >>> On Thu, Oct 22, 2015 at 6:12 PM, Andreas Gudian >> >>> >> >>> <andreas.gud...@gmail.com> wrote: >> >>>> Hi, >> >>>> >> >>>> A build that fails constantly has no value at all. A working Windows >> >>> >> >>> build on the other hand would be something that I'd consider quite >> >>> important - process spawning, communication and termination can behave >> >>> slightly different under different OS's. >> >>> >> >>>> Tibor and I are on Windows, but if someone else working on OSX or Linux >> >>> >> >>> starts changing something in that area, the missing Windows builds (or >> >> >> >> the >> >> >> >>> currently unusable jobs) could create a blind spot. >> >>> >> >>>> Could it be the ancient shadefire-version that causes hanging processes >> >>> >> >>> in our integration tests on those windows nodes? I never had any >> >>> problems >> >>> with it on my local machines, though. >> >>> >> >>>> Cheers, >> >>>> Andreas >> >>>> >> >>>> Am Donnerstag, 22. Oktober 2015 schrieb Tibor Digana : >> >>>>> Hi, >> >>>>> >> >>>>> Our CI build permanently fails due to locked files in workspace. >> >>>>> https://builds.apache.org/job/maven-surefire-windows/ >> >>>>> I reported an issue but this did not help >> >>> >> >>> https://issues.apache.org/jira/browse/INFRA-10547 >> >>> >> >>>>> Do we need Windows build? >> >>>>> It looks like there is only Windows1 and Windows2 machine. One is too >> >>> >> >>> slow and the next one has this problem with file system. >> >>> >> >>>>> I prefer working Win agent but the INFRA does not care. >> >>>>> >> >>>>> -- >> >>>>> Cheers >> >>>>> Tibor >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
