Skip to main content

[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:

  1. Launch the Installer
  2. Drag the Platform SDK Configuration link to the Installer’s title;
    1. accept switching to advanced mode
    2. Installer restarts, landing on the Variables page
  1. Click Next
  2. Check the Overwrite box
  3. Click Finish

 

What I’m (repeatably) seeing:

  1. The installer launches the new instance,
  2. The instance opens an Eclipse Updater window
  3. The while cloning eclipse.jdt.core, and getting to the instance’s Executing startup tasks: (10%) mark, hangs.
  4. 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

 

From: Ed Merks <ed.merks@xxxxxxxxx>
Sent: Thursday, December 31, 2020 5:59 AM
To: Richard Steiger <rsteiger@xxxxxxxxxxxxxxxx>
Cc: Eclipse JDT general developers list. <jdt-dev@xxxxxxxxxxx>
Subject: Re: Installs of eclipse-committers 2020-12 infinitely loops

 

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


Back to the top