Bugzilla – Full Text Bug Listing
| Summary: | Updating Maven Dependencies Hangs | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Rob Winch <rwinch> | ||||||||||
| Component: | m2e | Assignee: | Paul Tatavu <vladt> | ||||||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||||||
| Severity: | normal | ||||||||||||
| Priority: | P3 | CC: | igor, jbailey, jfarcand, Knut.Friedhelm, pascal, sergiu.gordea, timtsu+eclipsebugs, vladt | ||||||||||
| Version: | unspecified | ||||||||||||
| Target Milestone: | --- | ||||||||||||
| Hardware: | PC | ||||||||||||
| OS: | Linux | ||||||||||||
| Whiteboard: | |||||||||||||
| Attachments: |
|
||||||||||||
|
Description
Rob Winch
I should have also noted that Eclipse does not shut down properly when this happens (I must kill it). Are you able to reproduce the problem with a recent m2e 0.13 installed on a clean eclipse distribution from eclipse.org? (although m2e is expected to with STS, we are not able to trouble thirdparty/commercial distributions). Created attachment 191018 [details] Thread Dump and Eclipse Configuration Thank you for your prompt response. I was able to reproduce the issue with eclipse-j2ee-helious-sr2 with m2eclipse and m2e .13.x. I have attached a new zip containing both my Eclipse Configuration and the thread dump. This time running the hang occurred when downloading http://repository.jboss.com/maven2/opensymphony/sitemesh/2.3/sitemesh-2.3.jar I kept a close eye on the download and it hung for at least 5 minutes before I went to lunch. An hour later it was still hung. When trying to close Eclipse, it continues to hang and must be forcibly closed. A few observations on reproducing the issue. * We have a number of maven repositories in our poms, but the hang always seems to occur on jboss.com This could be coincidence, but I thought I would mention it. * The issue occurs more frequently when I have a large multi module build and have renamed my maven repository (a lot of downloads occurring). If desired, within the next few days I could attempt to find the time to create a dummy multi module build that reproduces this issue and submit it. Please let me know if there is anything else I can provide. PS: Initially I thought the issue was fixed because I noticed the stacks changed from org.jboss.netty.channel.DefaultChannelFuture.awaitUninterruptibly() to org.jboss.netty.channel.DefaultChannelFuture.awaitUninterruptibly(long, TimeUnit) I have not taken a look at the code, but I was thinking that because of the parameters passed in that it would use them to perform a timeout. However, this does not appear to be happening. Regards, Rob Yes, please provide standalone example projects that exhibits this behaviour. From my experience, springsource repository tends to be unreliable, but m2e obviously need to handle this better. The issue seems to be: https://gist.github.com/866617 It seems that AHC is unable to shut down properly, and that goes down to the Netty library. I suspect it may be an NIO bugs....do you think you can isolate a test case? I know it will not be simple. Couple of questions: + which Ubuntu and which kernel version are you using? + are you able to reproduce the issue on another machine or os? Thanks! -- Jeanfrancois (In reply to comment #5) > The issue seems to be: > > https://gist.github.com/866617 > > It seems that AHC is unable to shut down properly, and that goes down to the > Netty library. I suspect it may be an NIO bugs....do you think you can isolate > a test case? I know it will not be simple. I will do my best to try and isolate it a bit, but I think the best I will be able to do is create a project that reproduces the issue. > Couple of questions: > > + which Ubuntu and which kernel version are you using? $ uname -a Linux rwinch 2.6.35-27-generic #48-Ubuntu SMP Tue Feb 22 20:25:29 UTC 2011 i686 GNU/Linux > + are you able to reproduce the issue on another machine or os? I have seen this occur on Windows 7 as well. Thanks again for the excellent support, Rob OK thanks for the information. The fix is in AHC 1.6.3-SNAPSHOT https://github.com/sonatype/async-http-client/commit/2ae13b1075ac40e5028fae176257cd4add704a5a I will work with Igor to generate a patch you can use/test, but I'm 100% sure the fix will works :-) -- Jeanfrancois Created attachment 191122 [details] Sample Project and Thread Dump (In reply to comment #7) > OK thanks for the information. The fix is in AHC 1.6.3-SNAPSHOT > > https://github.com/sonatype/async-http-client/commit/2ae13b1075ac40e5028fae176257cd4add704a5a > > I will work with Igor to generate a patch you can use/test, but I'm 100% sure > the fix will works :-) > > -- Jeanfrancois Thanks for the update. I will be sure to try the patch as soon as it is posted. I know you might have already figured it out, but I thought I would post an update in hopes that my efforts could help in some way. Here is my status on isolating a test case.... I played around with this a bit this weekend, but I'm not entirely sure I have created a project that isolates the issue. The multi module build that I can reproduce this issue with is commercial, so I cannot share it. Additionally, it is very large, so isolating the issue takes quite a bit of time since each trial involves re-downloading the entire maven repository. I have confirmed that this issue is reproducible even when I am not behind a proxy. However, I am not convinced it is entirely deterministic. The other possibility is that the build is just very slow. Under most of the trials, the build seems to hang after about 20 minutes of slow progress when on a ~20 MB/s connection. It then hangs for at least another 20 minutes with the following tasks displayed in Eclipse (or something very similar): Importing Maven projects (9%) Initializing Javascript Tooling (Blocked: waiting for Importing Maven projects) Updating Maven Dependencies (Waiting) After making the last bit of changes, I let it run over night (not behind a proxy) and the build finished. However, it did not download all the dependencies. Refreshing the dependencies at that point produced a very quick retrieval of the dependencies that were missing and the project built just fine. I removed everything from my repository and let it run again this morning behind the proxy and it hung for over an hour. To clarify... * I have seen the issue with a slightly different project hang when not behind a proxy. Unfortunately I cannot submit this project since it still had some stuff in it that could identify the company (i.e. maven site, source code, etc) * I made a few changes and ran again (not behind a proxy) over night. The build worked, but it ran over night, so it may be that the builds are just really slow. As far as I know, I have no way to see how long it took since in the new version of the plugin the Maven console does not output the download times. * I took the same build and ran it (behind the proxy) and it hung for over an hour Reproducing the issue: 1) Install a fresh eclipse-jee-helios-SR2-linux-gtk.tar.gz 2) Install m2e .3.x 3) Rename or delete your local maven repository 4) Start a fresh workspace 5) Import the attached project as an existing maven project PS: All my eclipse and OS information is the same as the previous posting I updated m2e to use AHC 1.6.3-SNAPSHOT (which includes the fix from jfarcand). Please re-open this bug if you can reproduce it with the new m2e. The build containing the fix is available on our nightly update site: http://download.eclipse.org/technology/m2e/updates/N please give it a try and let us know what you see. This appears to have fixed the issue. Thanks again for the excellent support. URL above not found?????? m2e with correct combination of ahc/netty/wagon (our http transport layer) are part of indigo release "train". you can install it from indigo repository and download as part of "java" eclipse distribution. URL above not found?????? Got news for you -- I already have 0.12.1.20110112-1712, which still has this now multiple-year old bug. I am running Helios svc rel 2, Build Id 20110301-1815. Are you guys taking care of circular dependencies? Missing files? URLs temporarily not answering? Etc etc etc. Just speculating, because you still have a problem. (In reply to comment #15) > Got news for you -- I already have 0.12.1.20110112-1712, which still has this > now multiple-year old bug. I am running Helios svc rel 2, Build Id > 20110301-1815. > > Are you guys taking care of circular dependencies? Missing files? URLs > temporarily not answering? Etc etc etc. Just speculating, because you still > have a problem. Latest 0.13.0 release candidate can be installed from http://download.eclipse.org/technology/m2e/updates/M/. This is This is an Eclipse Update site/p2 repository; you must access it from Eclipse as described in http://help.eclipse.org/helios/index.jsp?topic=/org.eclipse.platform.doc.user/tasks/tasks-127.htm . There are two m2e features, make sure to install both. If you still see the problem, please attach the following 1. eclipse installation details (Help->About_Eclipse->Installation_Details->Configuration) 2. JVM thread dump 3. m2e log from .metadata/.plugins/org.eclipse.m2e.logback.configuration/*.log* At this point I am not sure if logs etc will be enough to troubleshoot the problem, so we need a sample standalone project and steps to reproduce the problem. PS: you may want to tone it down a notch I still get the update of the maven project configuration hanging forever in the 1.0 release. It is not possible to cancel that operation, i.e. I need to kill Eclipse. This happened very often in 0.12.1 and now after the upgrade to 1.0. How can I reopen that issue? Created attachment 198831 [details]
Thread dump with m2e 1.0.
Hmm, I just noticed that I now can't even start Eclipse anymore. It hangs on 'Initializing Java Tooling' and 'Updating Maven Configuration'. to help us narrow down the problem, can you try to reproduce the probem with clean/fresh eclipse 3.7 "for java developers"? Ok, I will try to reproduce with a clean install. (In reply to comment #21) > Ok, I will try to reproduce with a clean install. I tried to reproduce in a clean installation. Here I got a new problem, see #350939. There is no deadlock here, however this might be due to the missing class path container. I'll try to use an other example project, stay tuned... Look, guys, this issue and similar issues have plagued your user community for years. You keep claiming that it is "resolved fixed," and then someone else runs into it again. I and an engineer who reports to me saw it just a couple of months ago in Eclipse Helios. At that time, I googled around and found someone else reporting it way back in the middle ages (like 2004 or something), at which time King Henry the VIII marked it "resolved fixed." OBSERVATIONS: 1) The paradigm wherein Eclipse on startup does a boatload of typically unnecessary stuff by default is horrible, as it inflicts these kind of bugs on people when they exist. 2) It doesn't matter, and is therefore not legitimate to ask, if the bug can be produced in a clean install. You guys have dodged this kind of issue several times with stuff like that. If the bug exists at all, it must be fixed, the definition of "fixed" being that IT CAN NOT OCCUR AGAIN UNDER ANY CIRCUMSTANCES. Your task when confronted with a situation like this one is not to ask someone to re-install your buggy product. Instead, your task is to FIX THE BUG. 3) You should not release software that can not be stopped when it goes hog wild trying to download the entire Internet worth of Maven dependencies. This isn't Microsoft's task manager we are talking about. If the user says "kill the processing," then what you should do is... drum roll please... KILL THE PROCESSING! 4) Just because the user does a clean install and then reports a different bug, you do NOT have justification to mark this one as "resolved fixed." Particularly if it has been reported multiple times over the course of years. Before you close bugs, you need to do the due diligence necessary to know with certainty that they are indeed "resolved fixed." Which has not (yet again) been done here. We run into the same behaviour on our project with 2 machines by now. One of them was Ubuntu and the other one WinXp. 1. On Ubuntu we found out that there were some security policies preventing the download of dependencies. this caused the hang of eclipse. 2. On WinXp I have installed the following eclipse version: Version: Helios Release Build id: 20100617-1415 (c) Copyright Eclipse contributors and others 2000, 2010. All rights reserved. Visit http://eclipse.org/ Maven 2.0 integration 0.10.2 Copyright (c) 2007, 2008 Sonatype, Inc. All rights reserved. This program and the accompanying materials are made available under the terms of the Eclipse Public License v1.0 which accompanies this distribution, and is available at http://www.eclipse.org/legal/epl-v10.html I encountered the behaviour when updating more projects through the team synchornizing perspective and the automatic project build has started. I disabled the automatical project build, killed exlipse and started again. I finished synchronization and enabled the automatic project build. Everything worked ok afterwards. I asume this was some concurrency/locking problems Best regards, Sergiu Here is another workaround/problem description related to this ticket: I was finally able to unblock my Eclipse. In addition to disabling automatic build, you have to set preferences/maven/offline. After that you refresh the project, reenable preferences/maven/offline, and reeanble automatic build. We have a multi-level Project with 40-50 subprojects. This could be related to the fact that we are updating projects/pom files though the Team Synchronization perspective and the build project is run on many projects. Best regards, Sergiu |