Mailing-List: contact dev-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Maven Developers List" <dev@maven.apache.org>
MIME-Version: 1.0
Sender: kristian.rosenvold@zenior.no
In-Reply-To: <1820687.YWOl4ITBAd@herve-desktop>
References: 
 <CAKuVzBStHkN00b2ryj5Xiwp_mf9F3Wo4EaeBZt1rzzfKksMjBg@mail.gmail.com>
	<CAJZRQKx1W99-9+OPn0fpvOM5wRFdKjqiPNoqjLUbg+2QObsPjg@mail.gmail.com>
	<56503683.1060300@gmx.de>
	<1820687.YWOl4ITBAd@herve-desktop>
Date: Sat, 21 Nov 2015 15:13:15 +0100
Message-ID: 
 <CAJZRQKyQYBoHqTzyfOTn3cCnhfQPXf2AcA_5PcZzO7Y+yABSGw@mail.gmail.com>
Subject: Re: to delete windows build ?
From: Kristian Rosenvold <kristian.rosenvold@gmail.com>
To: Maven Developers List <dev@maven.apache.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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=C3=A9 BOUTEMY <herve.boutemy@free.fr>:
> 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 fo=
und,
> trying to show where the issue is
>
> Since there is currently no warning, I don't know how much issues will no=
w 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 rem=
ove).
>
> Because the only issue I fear is this hack makes the shade plugin have su=
pport
> for other plugins leaks: it's probably not easy to know how much plugins =
have
> leaks...
>
> Regards,
>
> Herv=C3=A9
>
> Le samedi 21 novembre 2015 10:16:51 Karl Heinz Marbaise a =C3=A9crit :
>> 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 l=
eaks
>> > 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 l=
ike
>> > 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/ma=
ven/
>> > 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.digana@googlemail.c=
om>:
>> >> 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 varia=
ble
>> >> "core.longPaths=3Dtrue" setup, see
>> >> https://issues.apache.org/jira/browse/INFRA-10724.
>> >>
>> >> On Fri, Oct 23, 2015 at 6:22 AM, Kristian Rosenvold <
>> >>
>> >> kristian.rosenvold@gmail.com> wrote:
>> >>> (Tibor; I'm taking this to the mailing list)
>> >>>
>> >>>
>> >>> It would appear that we are leaking file handles/resources when bein=
g
>> >>> 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 t=
o
>> >>> see if I can find anything.
>> >>>
>> >>> Kristian
>> >>>
>> >>>
>> >>>
>> >>> ---------- Forwarded message ----------
>> >>> From: Tibor Digana <tibor.digana@googlemail.com>
>> >>> Date: 2015-10-22 21:05 GMT+02:00
>> >>> Subject: Re: to delete windows build ?
>> >>> To: Andreas Gudian <andreas.gudian@gmail.com>
>> >>> Kopi: Kristian Rosenvold <kristian.rosenvold@gmail.com>
>> >>>
>> >>>>> 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 J=
IRA:
>> >>> "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
>> >>>
>> >>> <andreas.gudian@gmail.com> wrote:
>> >>>> Hi,
>> >>>>
>> >>>> A build that fails constantly has no value at all. A working Window=
s
>> >>>
>> >>> build on the other hand would be something that I'd consider quite
>> >>> important - process spawning, communication and termination can beha=
ve
>> >>> slightly different under different OS's.
>> >>>
>> >>>> Tibor and I are on Windows, but if someone else working on OSX or L=
inux
>> >>>
>> >>> 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 proce=
sses
>> >>>
>> >>> 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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org