Re: to delete windows build ?
eeks. 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] > > > > > /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 <
Re: to delete windows build ?
ventually 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] > > > > > /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 Ros
Re: to delete windows build ?
gt; > > > >> > > > > > >> > 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] > > > /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 ver
Re: to delete windows build ?
ation 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 > > > >>
Re: to delete windows build ?
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 > bei
Re: to delete windows build ?
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 : > > 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" : > >> >> 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 > >> >>> Date: 2015-10-22 21:05 GMT+02:00 > >> >>> Subject: Re: to delete
Re: to delete windows build ?
Who nowadays can rely on System.gc(). It may or may not trigger finalize(). Good job Kristian! I guess Kristian closed streams in MOJO execution() with no shutdown hook or something like that. On Sat, Nov 21, 2015 at 3:13 PM, Kristian Rosenvold < kristian.rosenv...@gmail.com> wrote: > 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 : > > 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 > >> >>> Date: 2015-10-22 21:05 GMT+02:00 > >> >>> Subject: Re: to delete windows build ? >
Re: to delete windows build ?
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 : > 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" : >> >> 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 >> >>> Date: 2015-10-22 21:05 GMT+02:00 >> >>> Subject: Re: to delete windows build ? >> >>> To: Andreas Gudian >> >>> Kopi: Kristian Rosenvold >> >>> >> >>>>> 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. >> >>> &
Re: to delete windows build ?
Hi regarding the System.gc() hack it's close to impossible to say how much gets freed. According to http://bugs.java.com/view_bug.do?bug_id=6668279 only unsed object references are discovered and _may_ get released. AFAIK streams or file handles aren't closed by GC directly, but sometimes when the finalyze() is implemented this may work. E.g. consider the Inflater *1) has a end() method which frees up the off-heap memory resources (because inflater uses zlib via JNI). As long as such Inflater objects aren't garbage collected they can occupy huge amount of memory. To avoid such, its recommended to use try-finally constructs or try-resources (Java7) to explicitly release the resources. Knowing this makes me even more wonder, why the comments in ShadeMojo:643 state that there are unclosed streams are freed. *1) https://docs.oracle.com/javase/7/docs/api/java/util/zip/Inflater.html Regards Martin @nitram509 Am 21.11.2015 um 11:13 schrieb Hervé BOUTEMY: > [...] > Do you have an idea of how much recoverable such leaks are with the > System.gc() hack? > [...] - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: to delete windows build ?
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" : > >> 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 > >>> Date: 2015-10-22 21:05 GMT+02:00 > >>> Subject: Re: to delete windows build ? > >>> To: Andreas Gudian > >>> Kopi: Kristian Rosenvold > >>> > >>>>> 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 > >>> > >>> 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
Re: to delete windows build ?
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" : 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 Date: 2015-10-22 21:05 GMT+02:00 Subject: Re: to delete windows build ? To: Andreas Gudian Kopi: Kristian Rosenvold 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 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
Re: to delete windows build ?
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 Any objections ? Kristian 5. nov. 2015 5.29 p.m. skrev "Tibor Digana" : > 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 > > Date: 2015-10-22 21:05 GMT+02:00 > > Subject: Re: to delete windows build ? > > To: Andreas Gudian > > Kopi: Kristian Rosenvold > > > > > > >>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 > > 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 > > > > > > > > > > -- > > Cheers > > Tibor > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > -- > Cheers > Tibor >
Re: to delete windows build ?
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 > Date: 2015-10-22 21:05 GMT+02:00 > Subject: Re: to delete windows build ? > To: Andreas Gudian > Kopi: Kristian Rosenvold > > > >>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 > 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 > > > > > -- > Cheers > Tibor > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- Cheers Tibor
Re: to delete windows build ?
The build was successful just once after workspace cleanup but failed on second run. We should therefore continue with INFRA-10657 <https://issues.apache.org/jira/browse/INFRA-10657>. For more info see: https://builds.apache.org/job/maven-surefire-windows/986 https://builds.apache.org/job/maven-surefire-windows/987 On Sun, Oct 25, 2015 at 11:49 AM, Kristian Rosenvold < kristian.rosenv...@gmail.com> wrote: > Based on code review I found a large number of close-statements that > were not in the mandated finally blocks, which would create resource > leakage on kill. > > I fixed this in bb99b232da0e93f2772be6945a410ea9ba666c4f, hope this > will help the situation on windows. > > Kristian > > 2015-10-23 17:26 GMT+02:00 Tibor Digana : > > The infra team made a cleaup of Jenkins workspace which really helped > once. > > Next time I triggered the build we got same symptoms as before: > > > > FATAL: Command "git clean -fdx" returned status code 1: > > stdout: Removing maven-failsafe-plugin/target/ > > stderr: warning: failed to remove surefire-integration-tests/target/ > > > > It looks like we have some files in test which leak. Therefore I asked > > Gavin [1] to find out those files which are held by a process. > > [1] https://issues.apache.org/jira/browse/INFRA-10650 > > > > > > > > > > On Fri, Oct 23, 2015 at 6:23 AM, Kristian Rosenvold-4 [via Maven] < > > ml-node+s40175n5850011...@n5.nabble.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 <[hidden email] > >> <http:///user/SendEmail.jtp?type=node&node=5850011&i=0>> > >> 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=5850011&i=1>> > >> Kopi: Kristian Rosenvold <[hidden email] > >> <http:///user/SendEmail.jtp?type=node&node=5850011&i=2>> > >> > >> > >> >>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] /user/SendEmail.jtp?type=node&node=5850011&i=3>> > >> 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 > >> > > >> > > >>
Re: to delete windows build ?
Thx Kristian. I will add JIRA issues for that in 2.19.1. I will ask INFRA to cleanup workspace agan before restarting the build. On Sun, Oct 25, 2015 at 11:49 AM, Kristian Rosenvold-4 [via Maven] < ml-node+s40175n5850189...@n5.nabble.com> wrote: > Based on code review I found a large number of close-statements that > were not in the mandated finally blocks, which would create resource > leakage on kill. > > I fixed this in bb99b232da0e93f2772be6945a410ea9ba666c4f, hope this > will help the situation on windows. > > Kristian > > 2015-10-23 17:26 GMT+02:00 Tibor Digana <[hidden email] > <http:///user/SendEmail.jtp?type=node&node=5850189&i=0>>: > > > The infra team made a cleaup of Jenkins workspace which really helped > once. > > Next time I triggered the build we got same symptoms as before: > > > > FATAL: Command "git clean -fdx" returned status code 1: > > stdout: Removing maven-failsafe-plugin/target/ > > stderr: warning: failed to remove surefire-integration-tests/target/ > > > > It looks like we have some files in test which leak. Therefore I asked > > Gavin [1] to find out those files which are held by a process. > > [1] https://issues.apache.org/jira/browse/INFRA-10650 > > > > > > > > > > On Fri, Oct 23, 2015 at 6:23 AM, Kristian Rosenvold-4 [via Maven] < > > [hidden email] <http:///user/SendEmail.jtp?type=node&node=5850189&i=1>> > 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=5850011&i=0>> > >> 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=5850011&i=1>> > >> Kopi: Kristian Rosenvold <[hidden email] > >> <http:///user/SendEmail.jtp?type=node&node=5850011&i=2>> > >> > >> > >> >>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=5850011&i=3>> > > >> 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 s
Re: to delete windows build ?
Based on code review I found a large number of close-statements that were not in the mandated finally blocks, which would create resource leakage on kill. I fixed this in bb99b232da0e93f2772be6945a410ea9ba666c4f, hope this will help the situation on windows. Kristian 2015-10-23 17:26 GMT+02:00 Tibor Digana : > The infra team made a cleaup of Jenkins workspace which really helped once. > Next time I triggered the build we got same symptoms as before: > > FATAL: Command "git clean -fdx" returned status code 1: > stdout: Removing maven-failsafe-plugin/target/ > stderr: warning: failed to remove surefire-integration-tests/target/ > > It looks like we have some files in test which leak. Therefore I asked > Gavin [1] to find out those files which are held by a process. > [1] https://issues.apache.org/jira/browse/INFRA-10650 > > > > > On Fri, Oct 23, 2015 at 6:23 AM, Kristian Rosenvold-4 [via Maven] < > ml-node+s40175n5850011...@n5.nabble.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 <[hidden email] >> <http:///user/SendEmail.jtp?type=node&node=5850011&i=0>> >> 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=5850011&i=1>> >> Kopi: Kristian Rosenvold <[hidden email] >> <http:///user/SendEmail.jtp?type=node&node=5850011&i=2>> >> >> >> >>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=5850011&i=3>> >> 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 >> >> >> >> >> -- >> Cheers >> Tibor >> >> - >> To unsubscribe, e-mail:
Re: to delete windows build ?
The infra team made a cleaup of Jenkins workspace which really helped once. Next time I triggered the build we got same symptoms as before: FATAL: Command "git clean -fdx" returned status code 1: stdout: Removing maven-failsafe-plugin/target/ stderr: warning: failed to remove surefire-integration-tests/target/ It looks like we have some files in test which leak. Therefore I asked Gavin [1] to find out those files which are held by a process. [1] https://issues.apache.org/jira/browse/INFRA-10650 On Fri, Oct 23, 2015 at 6:23 AM, Kristian Rosenvold-4 [via Maven] < ml-node+s40175n5850011...@n5.nabble.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 <[hidden email] > <http:///user/SendEmail.jtp?type=node&node=5850011&i=0>> > 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=5850011&i=1>> > Kopi: Kristian Rosenvold <[hidden email] > <http:///user/SendEmail.jtp?type=node&node=5850011&i=2>> > > > >>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=5850011&i=3>> > 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 > > > > > -- > Cheers > Tibor > > - > To unsubscribe, e-mail: [hidden email] > <http:///user/SendEmail.jtp?type=node&node=5850011&i=4> > For additional commands, e-mail: [hidden email] > <http:///user/SendEmail.jtp?type=node&node=5850011&i=5> > > > > -- > 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-tp5850011.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=unsubscribe_by_code&node=142166&code=dGlib3JkaWdhbmFAYXBhY2hlLm9yZ3wxNDIxNjZ8LTI4OTQ5MjEwMg==> > . > NAML > <http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_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-tp5850011p5850043.html Sent from the Maven Developers mailing list archive at Nabble.com.
Fwd: to delete windows build ?
(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 Date: 2015-10-22 21:05 GMT+02:00 Subject: Re: to delete windows build ? To: Andreas Gudian Kopi: Kristian Rosenvold >>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 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 -- Cheers Tibor - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
