[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jdt-dev] False alarm: Installs don't infinitely loop
|
Richard,
I believe the step that's taking very long after the clone from
the remote is finished is the part where the working tree is being
reset by JGit.
private static void resetHard(SetupTaskContext context, Git
git) throws Exception
{
context.log(Messages.GitCloneTaskImpl_ResettingHard_message);
ResetCommand command = git.reset();
command.setMode(ResetType.HARD);
command.call();
}
For a big project, I suppose that can take quite long. I don't
know if JGit itself provides additional logging flags/support;
that's something you could ask on the EGit forum; EGit also has an
Oomph setup. But I imagine it just takes as long as it takes...
In the Oomph setup engine, we only do simple logging and
monitoring of the activities (progress monitoring) of the
JobManager. If something fails, I expect it throws an exception
that's shown in Oomph's log, if it propagates that far, or in the
Error Log, if something captures/logs and then "swallows" it.
Regards,
Ed
On 05.01.2021 06:52, Richard Steiger
wrote:
Ed,
Following-up on my previous message, having
reviewed the installer’s console stream a bit more carefully,
I discovered that what I’ve been missing (step 3 of “What I’m
seeing” list) is that the first cloning (of
eclipse.jdt.core) isn’t followed (and after the first Resetting
hard event) by a repetition, but the updater instead
moves on to clone
eclipse.jdt.core.annotation (easily confused with first
clone), and over the course of about half an hour,
successfully built the new instance, with all expected limbs
properly attached.
The good news is that I’ve found no defects
in neither the Installer nor Updater, so no bug to file, etc.
The slightly unfortunate news is that the
clone operations are interspersed with
Resetting hard events, adding the long timeouts to the
mix, and drastically elongating the installation process, and
given how infrequently I’m guessing most eclipse devs need to
do installs, this seems like a pretty small whoop, not worth a
lot of further debugging. (So, just have another cup or two
of coffee on your break.) That said, I captured both the
Installer and Updater console outputs, and viewed the new
instance’s ErrorLog, and have found no errors nor backtraces
reflecting the hard resets. From my limited vantage point,
the timeouts are opaque, the trail cold.
Is there a straightforward, non-coding way
to enable tracing of the updater’s execution, and which would
shed useful light on the timeouts? If so, I’d be glad to
gather such data.
Regards,
-rjs
From: Richard Steiger
Sent: Friday, January 1, 2021 3:25 AM
To: Ed Merks <ed.merks@xxxxxxxxx>
Cc: Eclipse JDT general developers list.
<jdt-dev@xxxxxxxxxxx>
Subject: RE: Installs of eclipse-committers
2020-12 infinitely loops
Ed,
Apologies for any unclarity. My
objective is to create and install an Eclipse SDK instance,
thereby enabling me to work on some ECJ bugs.
The steps I’ve been using are:
- Launch the
Installer
- Drag the
Platform SDK Configuration link to the Installer’s title;
- accept
switching to advanced mode
- Installer
restarts, landing on the Variables page
- Click Next
- Check the
Overwrite box
- Click
Finish
What I’m (repeatably) seeing:
- The
installer launches the new instance,
- The
instance opens an Eclipse Updater window
- The while
cloning eclipse.jdt.core, and getting to the instance’s
Executing startup tasks: (10%) mark, hangs.
- Eventually
times-out, jump to step 3; continues until killed.
Here’s a shot of the Updater and the SDK
instance at this juncture:
Please let me know in what way this is
unclear. I’d be happy to share any logs that might help, or
otherwise team-up on any digging that might help.
Thanks for coaching this greenhorn.
-rjs
Richard,
It's not entirely clear what you're doing. What exact
steps would I need to follow to reproduce what you're
seeing? What exactly is your goal?
Your title sounds very general, "install committers
2020-12", but your details make it clear that you're
trying to set up some specific project(s). Perhaps you're
trying to do the following?
https://wiki.eclipse.org/Eclipse_Platform_SDK_Provisioning
Note that the installer does not clone repos nor does it
do builds. Those things happen in your installation
itself.
If you simply want "committers 2020-12" use the simple
model and do not choose any projects on the projects page.
Regards,
Ed
On 31.12.2020 12:07, Richard Steiger
wrote:
Hi, Ed,
I’m just getting back into eclipse
work after an 8 month gap. If I’m directing this issue
to you incorrectly, please advise.
I’ve tried several times starting
from a fresh Installer installation, selecting advanced
mode, filling-in the handful of params, and kicking it
off. The new workspace is spawned, a new instance is
started, and all seems to be working, with the Installer
cloning repos and building the branch. About 10 minutes
into this phase, the build appears to freeze, eventually
times-out, logs “Resetting hard” to the console, and
restarts the build. I’ve let it do this for 4 cycles,
so it’s entirely reproduceable. (BTW, FWIW, I’m
selecting 14.0.2 oracle for the JDK, so it doesn’t seem
like it’s a residual effect of
Bug 564816.)
Unlike the previous installer failures I encountered
3/29-4/3/20, there seem to be none of the prior issues
around IllegalArgumentExceptions, attempting to clone a
bent repo URL, repo server access denied, nor repo
connection timeouts (harder to tell, but seem to happen
in same place each cycle, so very likely due to heavy
loading).
Any suggestions what to try next?
Thanks,
-rjs