You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Tibor Digana <ti...@apache.org> on 2015/12/17 17:04:06 UTC
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+s40175n5852667h17@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-tp5850011p5852667.html
> To start a new topic under Maven Developers, email
> ml-node+s40175n142166h86@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-tp5850011p5855203.html
Sent from the Maven Developers mailing list archive at Nabble.com.
Re: to delete windows build ?
Posted by Kristian Rosenvold <kr...@apache.org>.
Afaik it can be released any time.
18. des. 2015 16.38 skrev "Hervé BOUTEMY" <he...@free.fr>:
> 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 <ti...@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+s40175n5852667h17@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+s40175n142166h86@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: to delete windows build ?
Posted by Tibor Digana <ti...@googlemail.com>.
I want to cut the release version 2.4.3 of m-shade-p.
On Fri, Dec 18, 2015 at 4:37 PM, Hervé BOUTEMY <he...@free.fr>
wrote:
> 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 <ti...@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+s40175n5852667h17@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+s40175n142166h86@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
Cheers
Tibor
Re: to delete windows build ?
Posted by Hervé BOUTEMY <he...@free.fr>.
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 <ti...@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+s40175n5852667h17@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+s40175n142166h86@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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: to delete windows build ?
Posted by Kristian Rosenvold <kr...@gmail.com>.
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 <ti...@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+s40175n5852667h17@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-tp5850011p5852667.html
> > To start a new topic under Maven Developers, email
> > ml-node+s40175n142166h86@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-tp5850011p5855203.html
> Sent from the Maven Developers mailing list archive at Nabble.com.
>