Bug 520386 - Context menu in history view table takes very long to appear when there is no Internet connectivity
Summary: Context menu in history view table takes very long to appear when there is no...
Status: RESOLVED FIXED
Alias: None
Product: EGit
Classification: Technology
Component: Mylyn (show other bugs)
Version: unspecified   Edit
Hardware: PC All
: P3 normal with 2 votes (vote)
Target Milestone: 5.6   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-07-31 17:41 EDT by Thomas Wolf CLA
Modified: 2019-09-08 16:22 EDT (History)
4 users (show)

See Also:


Attachments
requested dumps (78.05 KB, application/zip)
2018-04-10 01:08 EDT, glyphx CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Wolf CLA 2017-07-31 17:41:21 EDT
Reported in the forums at https://www.eclipse.org/forums/index.php/t/1085055/

jstack reveals that we're busy computing the local host name in org.eclipse.egit.internal.mylyn.ui.commit.TaskReferenceFactory.isSameHost().
Comment 1 Thomas Wolf CLA 2017-08-01 07:26:29 EDT
There is no way around InetAddress.getLocalHost() (and the subsequent getHostName() or getCanonicalHostName()) taking long when there is no network connectivity.

Several possibilities:

1. Use JGit's SystemReader.getInstance().getHostname() instead of InetAddress.getLocalHost().getHostName(). It does the same under the hood, but caches the result, so it'll be slow only the first time.

2. A variation of (1): pre-compute the host name in an early startup thread (via IStartup), so it'll already have been done in the background before it's needed. Even then it's possible that the user tries to show the context menu before that background thread is done, in which case we'll block again the first time.

3. Run the local host calculation in a separate job, join on it with a short timeout (and take it out of that isSameHost() method, which is called repeatedly in an inner loop). "Short timeout" might be something like 100ms. If not done by then, ignore. Might not work if the job framework decides to not start the job within the timeout.

4. Skip that local host check altogether. How common is it to have a mylyn task repository on localhost?

(1) and (2) will not react on changes in network connectivity -- we'll use whatever we got when we tried the first time. And short of writing a whole background polling machinery to determine whether any IPv4 or IPv6 NetworkInterfaces are up, there doesn't seem to be a way to be notified of connectivity changes in Java. Or does Platform have something like this already somewhere? (3) may still be too expensive.

I actually favor (4).
Comment 2 Thomas Wolf CLA 2017-09-17 04:35:34 EDT
Could I get a second opinion here, please? Our menus should work speedily regardless of Internet connectivity.
Comment 3 Donal Fellows CLA 2017-09-29 05:48:59 EDT
I've been noticing this issue, and that it is linked to the resolution of localhost on OSX (which I've been independently seeing issues with elsewhere as well) is unfortunate but unsurprising. Your plan to fix by method (4) seems reasonable to me from a user perspective.
Comment 4 Johan Wannheden CLA 2018-03-28 11:23:27 EDT
From a user's perspective also, I agree with Donal.

Working for a customer using a VPN connection, the ultra slow context menus are a show stopper.

Has there been any progress on this? The issue persists with Git integration for Eclipse 5.0.0.201803261130.
Comment 5 Thomas Wolf CLA 2018-04-01 05:58:56 EDT
(In reply to Johan Wannheden from comment #4)
> From a user's perspective also, I agree with Donal.
> 
> Working for a customer using a VPN connection, the ultra slow context menus
> are a show stopper.
> 
> Has there been any progress on this? The issue persists with Git integration
> for Eclipse 5.0.0.201803261130.

Having briefly looked at this:

1. You _do_ have internet connectivity.
2. The problematic context menu is the one in the Repositories View.

So most likely a different issue. 

On my Mac, I cannot reproduce the problem, not even with your big repo.

I suspect it's due to your home directory being on a network drive. Probably the slowness is caused by JGit trying to access your ~/.gitconfig.

JGit does cache the contents of ~/.gitconfig, but is also checks the last-modified time of that file on each access to the cache (and if changed, will reload it). That alone is expensive if the file is on a slow disk. See bug 456996.

Could you try to confirm? Take a few jstack dumps while waiting for the menu to come up, then send them to me. Then we can check what's up, and depending on the precise circumstances, we may be able to do something.
Comment 6 glyphx CLA 2018-04-05 13:18:42 EDT
(In reply to Thomas Wolf from comment #5)
> (In reply to Johan Wannheden from comment #4)
> > From a user's perspective also, I agree with Donal.
> > 
> > Working for a customer using a VPN connection, the ultra slow context menus
> > are a show stopper.
> > 
> > Has there been any progress on this? The issue persists with Git integration
> > for Eclipse 5.0.0.201803261130.
> 
> Having briefly looked at this:
> 
> 1. You _do_ have internet connectivity.
> 2. The problematic context menu is the one in the Repositories View.
> 
> So most likely a different issue. 
> 
> On my Mac, I cannot reproduce the problem, not even with your big repo.
> 
> I suspect it's due to your home directory being on a network drive. Probably
> the slowness is caused by JGit trying to access your ~/.gitconfig.
> 
> JGit does cache the contents of ~/.gitconfig, but is also checks the
> last-modified time of that file on each access to the cache (and if changed,
> will reload it). That alone is expensive if the file is on a slow disk. See
> bug 456996.
> 
> Could you try to confirm? Take a few jstack dumps while waiting for the menu
> to come up, then send them to me. Then we can check what's up, and depending
> on the precise circumstances, we may be able to do something.

I can confirm this is happening for me in the egit history window - on mac 10.12.5 eclipse Oxygen 3 (4.7.3).  When I right click a commit it takes 10 seconds for the context menu to come up.  If I delete my remotes, it comes up instantly. 

My .gitconfig is on my local SSD.  

If you can point me how to run jstack dumps while waiting for context menu I would be happy to contribute what I can to help get this resolved!

In the meantime a few questions...

I see this is in Component "Mylyn"... I don't (knowingly) use Mylyn... I guess it is used by EGit?  

Is there any workaround I can do in the meantime?  Uninstall Mylyn?  (would egit still work?)

Put something in my hosts file? nsswitch.conf? Or something else where I can force it to recognize my local host quicker?  

It is perhaps worth noting that "hostname" command returns my localhostname instantly in terminal.  

FYI - I am using an instance of enterprise github. (i.e. hosted by my company, not the public github.com) - I assume this does not matter, since the problem seems to be with resolving localhostname, but figured I would mention it.
Comment 7 glyphx CLA 2018-04-05 13:37:21 EDT
Also - to be clear - for me this happens whether there is network connectivity or not.
Comment 8 Thomas Wolf CLA 2018-04-06 02:28:35 EDT
(In reply to glyphx from comment #7)
> Also - to be clear - for me this happens whether there is network
> connectivity or not.

Yeah. This bug report is getting confused. Comments 1 to 3 were about a very precise problem occurring _only_ if there was no Internet connectivity.

Johan's problem in all likelihood is something different.

So is yours since you _do_ have internet connectivity. It is possible, though, that you and Johan experience the same problem. (My statement about a network home directory was a conjecture only.)

To run jstack:

1. Install a JDK. (It's not in the JRE distro.)
2. Start Eclipse.
3. Get the PID of the Eclipse process.
4. Open a terminal.
5. cd to the JDK bin directory -- most probably jstack isn't on your path.
6. Prepare running jstack: enter "./jstack -l PID > dump.txt", but don't hit <return> yet. (Of course, use the PID of the Eclipse process instead of "PID".)
7. Switch to Eclipse, try to bring up the history view's context menu
8. During these 10 seconds, switch back to the terminal and hit return.
9. Try to run several jstack dumps during these 10 seconds. On Linux, I'd in fact use a little loop like "for i in $(seq 1 10); do ./jstack -l PID > dump${i}.txt; sleep 1; done"
10. Then attach the dumps here.

Then I can take a look. There should be something in there that should give a clue as to what might be going on.
Comment 9 Thomas Wolf CLA 2018-04-06 02:32:39 EDT
(In reply to glyphx from comment #6)

> I see this is in Component "Mylyn"... I don't (knowingly) use Mylyn... I
> guess it is used by EGit?  

There is an EGit feature "Git integration for Eclipse - Task focused interface". The problem this bug report originally was about related to that.

> Is there any workaround I can do in the meantime?  Uninstall Mylyn?  (would
> egit still work?)

You could try to uninstall that "Task focused interface" feature.

> Put something in my hosts file? nsswitch.conf? Or something else where I can
> force it to recognize my local host quicker?  

Since you state below that the problem exists also when you do have Internet connectivity I don't think any of that might help.
Comment 10 glyphx CLA 2018-04-10 01:06:53 EDT
Thanks!  You rock! Took me a while to find it - they moved it since Neon - "Installation Details" used to be under Help menu on mac - now I have to go to "eclipse  > about eclipse" and then click "installation details"

Anyway - I uninstalled "Git integration for Eclipse - Task focused interface" and my problems are gone!!  To confirm - this should not affect me if I am not using Mylyn - correct? 

I went ahead and reinstalled the feature so that I could get you some dumps - I will attach them here.  

One interesting thing to note - on my work Macbookpro I have 
Neon ("Git integration for Eclipse - Task focused interface" 4.6.1) 
and 
Oxygen ("Git integration for Eclipse - Task focused interface" 4.9.2) 

And both of them have the problem.  I have another nearly identical MBP at home, same OS, and have neon installed there with 4.6.1 for the git task focused thing, and it does not have the problem... I thought maybe it had to do with the remote - so I switched remote on my work MBP but still had the problem until I uninstalled the "Git integration for Eclipse - Task focused interface"

Anyway - I think I am all good now with that feature disable for now.  What exactly does it do?  Want to make sure there are no unintended consequences of uninstalling it. 

Dumps uploading on next post.... (in case you still want to see them)...


BTW to be clear what was stated in the forum was
"If I disconnect and keep wifi off, it hangs. Same if I connect to wifi and sign in to our VPN (so the remote is accessible)...."

I took that to mean that it does hang when connected to wifi over VPN.  (not just when disconnected from the internet) - though maybe I misunderstood! :-)
Comment 11 glyphx CLA 2018-04-10 01:08:22 EDT
Created attachment 273503 [details]
requested dumps

requested dumps
Comment 12 Eclipse Genie CLA 2019-09-08 11:56:10 EDT
Gerrit change https://git.eclipse.org/r/148994 was merged to [master].
Commit: http://git.eclipse.org/c/egit/egit.git/commit/?id=306bc78bfcc7d6e745647d09dc3e8b320ef84f36