Mailing-List: contact dev-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Maven Developers List" <dev@maven.apache.org>
From: =?ISO-8859-1?Q?Herv=E9?= BOUTEMY <herve.boutemy@free.fr>
To: Maven Developers List <dev@maven.apache.org>
Subject: Re: to delete windows build ?
Date: Fri, 18 Dec 2015 16:37:54 +0100
Message-ID: <33735127.3eOoSsndnu@herve-desktop>
User-Agent: KMail/4.13.3 (Linux/3.13.0-73-generic; KDE/4.13.3; x86_64; ; )
In-Reply-To: 
 <CAJZRQKwo9vA+e37tm31AK0cXmGeYHOKZ4j6kHbC1inPaow=baA@mail.gmail.com>
References: 
 <CAJZRQKxHHk-XREwa5WjC86KE09=Pxn_0gVMg2+wqpvt6rpz3hA@mail.gmail.com>
 <CAKuVzBQ+ViZdPp+RyUZBb8s_BQ2TzurRhw3c5ehp1WNieWdk0Q@mail.gmail.com>
 <CAJZRQKwo9vA+e37tm31AK0cXmGeYHOKZ4j6kHbC1inPaow=baA@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"

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 r=
elease I=20
have to do...

Regards,

Herv=E9

Le vendredi 18 d=E9cembre 2015 07:53:19 Kristian Rosenvold a =E9crit :
> As long as shade is not released and updated it will probably come ba=
ck.
>=20
> I actually checked all the plugins for file leaks and there were no o=
ther
> leaks in the code that was being tested.
>=20
> K
>=20
> 2015-12-17 17:04 GMT+01:00 Tibor Digana <tibordigana@apache.org>:
> > Now the Windows build works [1] [2].
> >=20
> > [1] https://builds.apache.org/job/maven-surefire-windows/
> > [2] https://issues.apache.org/jira/browse/INFRA-10724
> >=20
> > On Sat, Nov 21, 2015 at 11:42 PM, Herv=E9 BOUTEMY [via Maven] <
> >=20
> > ml-node+s40175n5852667h17@n5.nabble.com> wrote:
> > > ok, IIUC, this tweak seems about internal m-shade-p leaks: in suc=
h
> > > conditions,
> > > now that leaks are fixed, yes, let's just remove the code (or fix=
 the
> > > plugin if
> > > another leak is found later)
> > >=20
> > > Regards,
> > >=20
> > > Herv=E9
> > >=20
> > > Le samedi 21 novembre 2015 15:13:15 Kristian Rosenvold a =E9crit =
:
> > > > 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 w=
ith a
> > > > sleep/retry or two sometimes actually is effective if weird :)
> > > >=20
> > > > Within shade I just fixed all of these leaks to use determinist=
ic
> > > > 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...
> > > >=20
> > > > Kristian
> > > >=20
> > > > 2015-11-21 11:13 GMT+01:00 Herv=E9 BOUTEMY <[hidden email]
> > >=20
> > > <http:///user/SendEmail.jtp?type=3Dnode&node=3D5852667&i=3D0>>:
> > > > > yes, should be deleted from a plugin silently doing such hack=
s: if
> > > > > we
> > >=20
> > > try
> > >=20
> > > > > to work around leaks issues, it should at least advertise tha=
t a
> > > > > leak
> > >=20
> > > was
> > >=20
> > > > > found, trying to show where the issue is
> > > > >=20
> > > > > Since there is currently no warning, I don't know how much is=
sues
> >=20
> > will
> >=20
> > > now
> > >=20
> > > > > be visible if the plugin simply fails on such (recoverable) l=
eaks
> > > > >=20
> > > > > Do you have an idea of how much recoverable such leaks are wi=
th the
> > > > > System.gc() hack?
> > > > >=20
> > > > > Just to choose if the removal should be done in 2 phases (war=
n
> > > > > before
> > > > > remove).
> > > > >=20
> > > > > Because the only issue I fear is this hack makes the shade pl=
ugin
> >=20
> > have
> >=20
> > > > > support for other plugins leaks: it's probably not easy to kn=
ow how
> > >=20
> > > much
> > >=20
> > > > > plugins have leaks...
> > > > >=20
> > > > > Regards,
> > > > >=20
> > > > > Herv=E9
> > > > >=20
> > > > > Le samedi 21 novembre 2015 10:16:51 Karl Heinz Marbaise a =E9=
crit :
> > > > >> Hi Kristian,
> > > > >>=20
> > > > >> On 11/21/15 9:33 AM, Kristian Rosenvold wrote:
> > > > >> > As some of you may have noticed, I have fixed a bunch of f=
ile
> > >=20
> > > handle
> > >=20
> > > > >> > leaks
> > > > >> > in the last weeks. This may eventually make running a CI o=
n
> >=20
> > windows
> >=20
> > > > >> > feasible :)
> > > > >> >=20
> > > > >> > The shade plugin was leaking like a sieve, and should now =
be
> > > > >> > fully
> > > > >> > watertight. There seems to be a few bits of silly code tha=
t I'd
> > >=20
> > > just
> > >=20
> > > > >> > like
> > > > >> > to remove, since the root cause in all likelyhood is fixed=
:
> > > > >> >=20
> > > > >> > For instance this;
> > >=20
> > > https://maven.apache.org/plugins/maven-shade-plugin/xref/org/apac=
he/mav
> > >=20
> > > > >> > en/
> > > > >> > plugins/shade/mojo/ShadeMojo.html#L643
> > > > >>=20
> > > > >> This is definitively a thing which should be deleted...
> > > > >>=20
> > > > >> > Any objections ?
> > > > >>=20
> > > > >> No..
> > > > >>=20
> > > > >> > Kristian
> > > > >> >=20
> > > > >> > 5. nov. 2015 5.29 p.m. skrev "Tibor Digana"
> > >=20
> > > <[hidden email] <http://
> >=20
> > /user/SendEmail.jtp?type=3Dnode&node=3D5852667&i=3D1>>:
> > > > >> >> 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 a=
nd Git
> > > > >> >> variable
> > > > >> >> "core.longPaths=3Dtrue" setup, see
> > > > >> >> https://issues.apache.org/jira/browse/INFRA-10724.
> > > > >> >>=20
> > > > >> >> On Fri, Oct 23, 2015 at 6:22 AM, Kristian Rosenvold <
> > > > >> >>=20
> > > > >> >> [hidden email]
> > >=20
> > > <http:///user/SendEmail.jtp?type=3Dnode&node=3D5852667&i=3D2>> wr=
ote:
> > > > >> >>> (Tibor; I'm taking this to the mailing list)
> > > > >> >>>=20
> > > > >> >>>=20
> > > > >> >>> It would appear that we are leaking file handles/resourc=
es when
> > >=20
> > > being
> > >=20
> > > > >> >>> killed by jenkins. This is not entirely surprising, sinc=
e this
> >=20
> > is
> >=20
> > > > >> >>> notoriously hard to get right. Does anyone know how the =
timeout
> > >=20
> > > in
> > >=20
> > > > >> >>> jenkins kills our process ? (If it's the equivalent of k=
ill -9
> > >=20
> > > we're
> > >=20
> > > > >> >>> in trouble no matter what, but usually some softer means=
 is
> > > > >> >>> used
> > > > >> >>> first....)
> > > > >> >>>=20
> > > > >> >>> I'll montor for resurce leaks while killing processes th=
is
> > >=20
> > > weekend to
> > >=20
> > > > >> >>> see if I can find anything.
> > > > >> >>>=20
> > > > >> >>> Kristian
> > > > >> >>>=20
> > > > >> >>>=20
> > > > >> >>>=20
> > > > >> >>> ---------- Forwarded message ----------
> > > > >> >>> From: Tibor Digana <[hidden email]
> > >=20
> > > <http:///user/SendEmail.jtp?type=3Dnode&node=3D5852667&i=3D3>>
> > >=20
> > > > >> >>> Date: 2015-10-22 21:05 GMT+02:00
> > > > >> >>> Subject: Re: to delete windows build ?
> > > > >> >>> To: Andreas Gudian <[hidden email]
> > >=20
> > > <http:///user/SendEmail.jtp?type=3Dnode&node=3D5852667&i=3D4>>
> > >=20
> > > > >> >>> Kopi: Kristian Rosenvold <[hidden email]
> > >=20
> > > <http:///user/SendEmail.jtp?type=3Dnode&node=3D5852667&i=3D5>>
> > >=20
> > > > >> >>>>> Could it be the ancient shadefire-version that causes =
hanging
> > > > >> >>>>> processes
> > > > >> >>>=20
> > > > >> >>> in our integration tests on those windows nodes?
> > > > >> >>> I do not know since I could not reproduce this issue on =
my
> > >=20
> > > system.
> > >=20
> > > > >> >>> IMHO the files are locked after the job has timed out. M=
y words
> > >=20
> > > in
> > >=20
> > > > >> >>> JIRA:
> > > > >> >>> "The build setup says that the build timeout is 69 min. =
The
> > > > >> >>> bild
> > >=20
> > > was
> > >=20
> > > > >> >>> running 64 which is very close."
> > > > >> >>>=20
> > > > >> >>> I should reopen the bug and ask INFRA to clean up the
> > > > >> >>> workspace.
> > > > >> >>>=20
> > > > >> >>> I expected INFRA to find out the root cause. The time ou=
t issue
> > >=20
> > > is a
> > >=20
> > > > >> >> guess.
> > > > >> >>=20
> > > > >> >>> Cheers
> > > > >> >>> Tibor
> > > > >> >>>=20
> > > > >> >>> On Thu, Oct 22, 2015 at 6:12 PM, Andreas Gudian
> > > > >> >>>=20
> > > > >> >>> <[hidden email]
> > >=20
> > > <http:///user/SendEmail.jtp?type=3Dnode&node=3D5852667&i=3D6>> wr=
ote:
> > > > >> >>>> Hi,
> > > > >> >>>>=20
> > > > >> >>>> A build that fails constantly has no value at all. A wo=
rking
> > >=20
> > > Windows
> > >=20
> > > > >> >>> build on the other hand would be something that I'd cons=
ider
> > >=20
> > > quite
> > >=20
> > > > >> >>> important - process spawning, communication and terminat=
ion can
> > > > >> >>> behave
> > > > >> >>> slightly different under different OS's.
> > > > >> >>>=20
> > > > >> >>>> Tibor and I are on Windows, but if someone else working=
 on OSX
> > >=20
> > > or
> > >=20
> > > > >> >>>> Linux
> > > > >> >>>=20
> > > > >> >>> starts changing something in that area, the missing Wind=
ows
> > >=20
> > > builds
> > >=20
> > > > >> >>> (or
> > > > >> >>=20
> > > > >> >> the
> > > > >> >>=20
> > > > >> >>> currently unusable jobs) could create a blind spot.
> > > > >> >>>=20
> > > > >> >>>> Could it be the ancient shadefire-version that causes h=
anging
> > > > >> >>>> processes
> > > > >> >>>=20
> > > > >> >>> in our integration tests on those windows nodes? I never=
 had
> > > > >> >>> any
> > > > >> >>> problems
> > > > >> >>> with it on my local machines, though.
> > > > >> >>>=20
> > > > >> >>>> Cheers,
> > > > >> >>>> Andreas
> > > > >> >>>>=20
> > > > >> >>>> Am Donnerstag, 22. Oktober 2015 schrieb Tibor Digana :
> > > > >> >>>>> Hi,
> > > > >> >>>>>=20
> > > > >> >>>>> Our CI build permanently fails due to locked files in
> > >=20
> > > workspace.
> > >=20
> > > > >> >>>>> https://builds.apache.org/job/maven-surefire-windows/
> > > > >> >>>>> I reported an issue but this did not help
> > > > >> >>>=20
> > > > >> >>> https://issues.apache.org/jira/browse/INFRA-10547
> > > > >> >>>=20
> > > > >> >>>>> Do we need Windows build?
> > > > >> >>>>> It looks like there is only Windows1 and Windows2 mach=
ine.
> > > > >> >>>>> One
> > >=20
> > > is
> > >=20
> > > > >> >>>>> too
> > > > >> >>>=20
> > > > >> >>> slow and the next one has this problem with file system.=

> > > > >> >>>=20
> > > > >> >>>>> I prefer working Win agent but the INFRA does not care=
.
> > > > >> >>>>>=20
> > > > >> >>>>> --
> > > > >> >>>>> Cheers
> > > > >> >>>>> Tibor
> >=20
> > -------------------------------------------------------------------=
--
> >=20
> > > > >> To unsubscribe, e-mail: [hidden email]
> > >=20
> > > <http:///user/SendEmail.jtp?type=3Dnode&node=3D5852667&i=3D7>
> > >=20
> > > > >> For additional commands, e-mail: [hidden email]
> > >=20
> > > <http:///user/SendEmail.jtp?type=3Dnode&node=3D5852667&i=3D8>
> > >=20
> > > > > -------------------------------------------------------------=
-------
> > > > > -
> > > > > To unsubscribe, e-mail: [hidden email]
> > >=20
> > > <http:///user/SendEmail.jtp?type=3Dnode&node=3D5852667&i=3D9>
> > >=20
> > > > > For additional commands, e-mail: [hidden email]
> > >=20
> > > <http:///user/SendEmail.jtp?type=3Dnode&node=3D5852667&i=3D10>
> > >=20
> > > > ---------------------------------------------------------------=
------
> > > > To unsubscribe, e-mail: [hidden email]
> > >=20
> > > <http:///user/SendEmail.jtp?type=3Dnode&node=3D5852667&i=3D11>
> > >=20
> > > > For additional commands, e-mail: [hidden email]
> > >=20
> > > <http:///user/SendEmail.jtp?type=3Dnode&node=3D5852667&i=3D12>
> > >=20
> > >=20
> > > -----------------------------------------------------------------=
----
> > > To unsubscribe, e-mail: [hidden email]
> > > <http:///user/SendEmail.jtp?type=3Dnode&node=3D5852667&i=3D13>
> > > For additional commands, e-mail: [hidden email]
> > > <http:///user/SendEmail.jtp?type=3Dnode&node=3D5852667&i=3D14>
> > >=20
> > >=20
> > >=20
> > > ------------------------------
> > > If you reply to this email, your message will be added to the dis=
cussion
> >=20
> > > below:
> > http://maven.40175.n5.nabble.com/Fwd-to-delete-windows-build-tp5850=
011p585
> > 2667.html>=20
> > > To start a new topic under Maven Developers, email
> > > ml-node+s40175n142166h86@n5.nabble.com
> > > To unsubscribe from Maven Developers, click here
> > > <
> >=20
> > http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=3Du=
nsubscrib
> > e_by_code&node=3D142166&code=3DdGlib3JkaWdhbmFAYXBhY2hlLm9yZ3wxNDIx=
NjZ8LTI4OTQ
> > 5MjEwMg=3D=3D>=20
> > > .
> > > NAML
> > > <
> >=20
> > http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=3Dm=
acro_view
> > er&id=3Dinstant_html%21nabble%3Aemail.naml&base=3Dnabble.naml.names=
paces.Basic
> > Namespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.=
templat
> > e.NodeNamespace&breadcrumbs=3Dnotify_subscribers%21nabble%3Aemail.n=
aml-insta
> > nt_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail=
.naml
> >=20
> >=20
> >=20
> >=20
> >=20
> >=20
> > --
> > View this message in context:
> > http://maven.40175.n5.nabble.com/Fwd-to-delete-windows-build-tp5850=
011p585
> > 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