Hello
I tried to track down such a problem a few weeks ago (by using the CTRL-break
approach), and I can remember the following, (a little lengthy, and hopefully
somehow understandable :-) )
One reason for blocking could be:
- downloading artefacts via HTTP causes TCP connections to be opened and
closed again
- closing such connections can be done in different ways. One way (i'm
afraid that's the default behaviour of the involved base classes), is, to let
the socket "linger" for a certain time.
- when MANY artifacts are downloaded (or only tried to download, which
is true here, especially, when you activate the "download sources" option in
m2eclipse) these "lingering" connections probably can eat up the available
network resources. Using netstat -a shows such connections in "*_WAIT" state.
The default port-range for such (I think) anonymous client Sockets is limited
to (I think) 1024-5000)
- the effect is, that the "n+1"'th attempt to download another artifact
has to wait, until such lingering sockets are freed (after 1-2 minutes on
Windows, I think).
One approach I wanted to do, was, NOT to use the "linger" option on the
Sockets. Unfortunately, doing this is not easily possible, because we are
talking here about sun classes, which reside in rt.jar (I hope I remember
correctly). This code is USED by the "http-lightweight" wagon implementation.
Unfortunately, I did NOT find a way to use the "normal/not lightweight" http
wagon implementation, for an alternative way to download artifacts
One more thing, that also came into play here, was, that we have unneccesarily
went thru our HTTP proxy for inTRAnet access to our Proximity Server, which in
turn also introduced similar "linger-" problems on that server, too. (Funny
thing during Maven-training sessions, when N developers do the same thing....)
Another bad influence here was the way we have setup proximity: for every
attemt to downlad an artefact, there were about 4 remote accesses necessary
(e.g apache-snapshot, apache-snapshots, codehaus-snapshot, codehaus-snapshots
etc). We have now cleaned up this a little by using the Proximity "group"
feature, so that the number of http requests per single artefact download was
reduced.
So, to sum up,
- in our situation, this was not a problem of m2eclipse, but maven (and
wagon), and our "bad" maven infrastructure setup.
- maybe the "lightweight http wagon" implementation should be improved e.g
to reuse TCP connections in HTTP access (don't know if this is possible in
HTTP....).
Hope it helps a little.
DI Gerhard Langs
ACT Software Development
SYSTEMA
Human Information Systems
Gesellschaft m.b.H.
Pachergasse 4
A-4400 Steyr
S \\ //// S T E M A
\\ //// E-Mail: mailto:[EMAIL PROTECTED]
\\ //// Phone: +43 (0)7252 587 1662
//// Mobile: -
//// FAX: +43 (0)7252 587 300
//// WEB: http://www.systema.info
Firmenbuchnummer FN 186491b, Landesgericht Steyr, Firmensitz: A-4400 Steyr,
Pachergasse 4
-----Ursprüngliche Nachricht-----
Von: Eugene Kuleshov [mailto:[EMAIL PROTECTED]
Gesendet: Freitag, 25. Januar 2008 20:28
An: [email protected]
Betreff: Re: [m2eclipse-user] Maven classpath container refresh job hanging
Pappara,
I've added couple FAQ entries about that. It is possible that you are
hitting a bug, but to narrow it down please see the following page.
http://docs.codehaus.org/display/M2ECLIPSE/Project+FAQ#ProjectFAQ-Classpathcontainerrefreshjobneverfinishes
regards,
Eugene
Papapara Tudu wrote:
> Hello,
> I have the Maven plugin v. 0.12. running on Eclipse Europa. Quite often the
> plugin kicks off the "maven classpath container refresh job" but this job
> hangs at 0% and never finishes. Many tasks I want to do with Eclipse (e.g.
> renaming files) always wait for the refresh job to finish which means I
> cannot perform a number of things.
> What could the reason for this be?
>
> Thanks,
> Papapara Tudu
>
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
