ok, IIUC, this tweak seems about internal m-shade-p leaks: in such conditions, now that leaks are fixed, yes, let's just remove the code (or fix the plugin if another leak is found later)
Regards, Hervé Le samedi 21 novembre 2015 15:13:15 Kristian Rosenvold a écrit : > 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 <[email protected]>: > > 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/mav > >> > en/ > >> > 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" <[email protected]>: > >> >> 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 < > >> >> > >> >> [email protected]> 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 <[email protected]> > >> >>> Date: 2015-10-22 21:05 GMT+02:00 > >> >>> Subject: Re: to delete windows build ? > >> >>> To: Andreas Gudian <[email protected]> > >> >>> Kopi: Kristian Rosenvold <[email protected]> > >> >>> > >> >>>>> 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 > >> >>> > >> >>> <[email protected]> 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: [email protected] > >> For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
