is there something to do on m-shade-p before releasing 2.4.3? because this fixed plugin version would perfectly fit the parent poms release I have to do...
Regards, Hervé Le vendredi 18 décembre 2015 07:53:19 Kristian Rosenvold a écrit : > As long as shade is not released and updated it will probably come back. > > I actually checked all the plugins for file leaks and there were no other > leaks in the code that was being tested. > > K > > 2015-12-17 17:04 GMT+01:00 Tibor Digana <tibordig...@apache.org>: > > Now the Windows build works [1] [2]. > > > > [1] https://builds.apache.org/job/maven-surefire-windows/ > > [2] https://issues.apache.org/jira/browse/INFRA-10724 > > > > On Sat, Nov 21, 2015 at 11:42 PM, Hervé BOUTEMY [via Maven] < > > > > ml-node+s40175n5852667...@n5.nabble.com> wrote: > > > 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 <[hidden email] > > > > > > <http:///user/SendEmail.jtp?type=node&node=5852667&i=0>>: > > > > > 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" > > > > > > <[hidden email] <http:// > > > > /user/SendEmail.jtp?type=node&node=5852667&i=1>>: > > > > >> >> 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 < > > > > >> >> > > > > >> >> [hidden email] > > > > > > <http:///user/SendEmail.jtp?type=node&node=5852667&i=2>> 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 <[hidden email] > > > > > > <http:///user/SendEmail.jtp?type=node&node=5852667&i=3>> > > > > > > > >> >>> Date: 2015-10-22 21:05 GMT+02:00 > > > > >> >>> Subject: Re: to delete windows build ? > > > > >> >>> To: Andreas Gudian <[hidden email] > > > > > > <http:///user/SendEmail.jtp?type=node&node=5852667&i=4>> > > > > > > > >> >>> Kopi: Kristian Rosenvold <[hidden email] > > > > > > <http:///user/SendEmail.jtp?type=node&node=5852667&i=5>> > > > > > > > >> >>>>> 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 > > > > >> >>> > > > > >> >>> <[hidden email] > > > > > > <http:///user/SendEmail.jtp?type=node&node=5852667&i=6>> 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: [hidden email] > > > > > > <http:///user/SendEmail.jtp?type=node&node=5852667&i=7> > > > > > > > >> For additional commands, e-mail: [hidden email] > > > > > > <http:///user/SendEmail.jtp?type=node&node=5852667&i=8> > > > > > > > > -------------------------------------------------------------------- > > > > > - > > > > > To unsubscribe, e-mail: [hidden email] > > > > > > <http:///user/SendEmail.jtp?type=node&node=5852667&i=9> > > > > > > > > For additional commands, e-mail: [hidden email] > > > > > > <http:///user/SendEmail.jtp?type=node&node=5852667&i=10> > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [hidden email] > > > > > > <http:///user/SendEmail.jtp?type=node&node=5852667&i=11> > > > > > > > For additional commands, e-mail: [hidden email] > > > > > > <http:///user/SendEmail.jtp?type=node&node=5852667&i=12> > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [hidden email] > > > <http:///user/SendEmail.jtp?type=node&node=5852667&i=13> > > > For additional commands, e-mail: [hidden email] > > > <http:///user/SendEmail.jtp?type=node&node=5852667&i=14> > > > > > > > > > > > > ------------------------------ > > > If you reply to this email, your message will be added to the discussion > > > > > below: > > http://maven.40175.n5.nabble.com/Fwd-to-delete-windows-build-tp5850011p585 > > 2667.html> > > > To start a new topic under Maven Developers, email > > > ml-node+s40175n142166...@n5.nabble.com > > > To unsubscribe from Maven Developers, click here > > > < > > > > http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscrib > > e_by_code&node=142166&code=dGlib3JkaWdhbmFAYXBhY2hlLm9yZ3wxNDIxNjZ8LTI4OTQ > > 5MjEwMg==> > > > . > > > NAML > > > < > > > > http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=macro_view > > er&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.Basic > > Namespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.templat > > e.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-insta > > nt_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml > > > > > > > > > > > > > > -- > > View this message in context: > > http://maven.40175.n5.nabble.com/Fwd-to-delete-windows-build-tp5850011p585 > > 5203.html Sent from the Maven Developers mailing list archive at > > Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
