Eclipse hangs in m2eclipse DefaultWagonManager.getRemoteFile

This isn’t a constructive post – I am going to vent about yet another reason I feel the combination of Maven-Subversion-Eclipse-AspectJ is the Bermuda triangle (er, make that square) of Java development.

I hit a hang tonight in Eclipse that comes from m2eclipse. I have seen this before, am irritated and I just want to vent about it.

Our toolset:

• Eclipse 3.5
• AspectJ Dev Tools 2.0.2
• m2eclipse .10.0.2010
• Subclipse 1.6.10

We have many modules. When I work against trunk, I almost always set Maven to offline mode after doing a full build. I don’t need to be on the tip for what I do.

The reason I evoke Bermuda when referring to this combination is the general unreliability I have when working. Eclipse arbitrarily rebuilds entire projects with a single line of Java changed. AspectJ fails to weave. Eclipse hangs for minutes at a time. On and on. This post is about one cause of the hang issue.

Annoying Hangs in Eclipse

I sporadically get hung up on calls to the Maven repo or Subversion. Eclipse will hang for minutes. I have started to monitor the stack traces, and they are so far they are m2eclipse or subclipse related.

As a good open source citizen, I should really stop what I am doing for half a day when this happens to try and figure out what is going wrong. Better yet, see if anyone else has had the problem and already reported it.

After tonight’s 5 minute hang, I did a search. I found other people with the problem (from 2008), yet no answer.

"Worker-9" prio=10 tid=0x0ab96000 nid=0xdf7 in Object.wait() [0x5eacd000]
   java.lang.Thread.State: WAITING (on object monitor)
    at java.lang.Object.wait(Native Method)
    - waiting on <0xaffea3e8> (a org.apache.maven.wagon.providers.http.JettyClientHttpWagon$WagonExchange)
    at java.lang.Object.wait(Object.java:485)
    at org.eclipse.jetty.client.HttpExchange.waitForDone(HttpExchange.java:134)
    - locked <0xaffea3e8> (a org.apache.maven.wagon.providers.http.JettyClientHttpWagon$WagonExchange)
    at org.apache.maven.wagon.providers.http.JettyClientHttpWagon.sendAndWait(JettyClientHttpWagon.java:245)
    at org.apache.maven.wagon.providers.http.JettyClientHttpWagon.getIfNewer(JettyClientHttpWagon.java:347)
    at org.apache.maven.wagon.providers.http.JettyClientHttpWagon.getIfNewer(JettyClientHttpWagon.java:302)
    at org.apache.maven.repository.legacy.DefaultWagonManager.getRemoteFile(DefaultWagonManager.java:292)
    at org.apache.maven.repository.legacy.DefaultWagonManager.getArtifact(DefaultWagonManager.java:99)
    at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:247)
    at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:507)
    at org.apache.maven.repository.legacy.LegacyRepositorySystem.resolve(LegacyRepositorySystem.java:325)
    at org.apache.maven.project.RepositoryModelResolver.resolveModel(RepositoryModelResolver.java:171)
    at org.apache.maven.model.building.DefaultModelBuilder.readParentExternally(DefaultModelBuilder.java:582)
    at org.apache.maven.model.building.DefaultModelBuilder.readParent(DefaultModelBuilder.java:449)
    at org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:182)
    at org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:117)
    at org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:117)
    at org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:81)
    at org.maven.ide.eclipse.internal.embedder.MavenImpl.readProject(MavenImpl.java:418)
    at org.maven.ide.eclipse.internal.project.MavenProjectManagerImpl$Refresher.phaseOne(MavenProjectManagerImpl.java:448)
    at org.maven.ide.eclipse.internal.project.MavenProjectManagerImpl.refresh(MavenProjectManagerImpl.java:368)
    at org.maven.ide.eclipse.internal.project.MavenProjectManagerRefreshJob.run(MavenProjectManagerRefreshJob.java:93)
    at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)

What am I going to do about it?

I know what I should do. Every time I hit an annoying problem, I should drop what I am doing and try and debug it.

I tried debugging the AspectJ issue, and gave up after a lot of problems getting a working debug environment with matching source files for everything. So I would like to help debug this one, but I just don’t have the desire to fight that again.

There is an easy workaround. I was not on my corporate VPN when this happened. I have only seen this problem when off the VPN. Therefore, I can just log into VPN all the time and the problem is avoided.

But I shouldn’t have to do that. My Maven settings clearly indicate an offline build.

If you are on this page, you must be having this same problem (I don’t have subscribers to this blog). Let me know with a comment. If others are annoyed maybe I will devote some time to debugging.

Technorati Tags: eclipse,maven

Eclipse missing from JPS (Java Process Status) command results list

It has been a while since I have posted. I have been working on some interesting stuff, but somehow didn’t manage to post about it. I will start to correct that.

I had a lot of work to do leading up to this past week. I had a couple of demos due for a big trade show at work. I hit a lot of bumps in the road due to infrastructure problems. I made a list, and I am working through them now that the deadlines are over. The next few posts will probably be about solutions to those.

The one covered here is pretty lame, but I’ll post it anyway.

Java Process Status command

I use the Java Process Status command line tool enough to want it to work perfectly. But, by default, it doesn’t. After launching Eclipse, I would execute JPS and get results like this:

plaird@plaird-laptop:~$ jps
18589 Jps
18339

If I launched multiple copies of Eclipse with different workspaces, I would predictably get:

plaird@plaird-laptop:~$ jps
19369
18339
19388 Jps

This isn’t a big problem, but its annoying. I put it on the list, and looked into it tonight. The reason is simple, and so is the solution.

JPS only works when using the standard Java launcher

The clue comes from the JPS documentation. It states:

The jps command uses the java launcher to find the class name and arguments passed to the main method. If the target JVM is started with a custom launcher, the class name (or JAR file name) and the arguments to the main method will not be available.

Well, that explains it because as many people know…

Eclipse uses a custom (native) launcher

After installing Eclipse, you are provided with a handy executable in the Eclipse directory. Invoking this thing launches Eclipse. Under the hood, it uses platform specific code to make it happen. The main benefit for doing this is to ensure that Eclipse is contained within a single OS process. The native code launches the JVM within its same process using a custom launcher. This appears to be a problem, but…

There is a way to use the standard launcher for Eclipse

However, you can revert to using the standard launcher. As per the launcher docs, there are several ways to do this. The way I chose is to make sure my eclipse.ini has these lines:

-vm
/usr/lib/jvm/java-6-sun-1.6.0.16/bin/java

Since the path for the vm arg is the standard Java launcher, it uses that instead of the custom launcher. Now look at my JPS results:

plaird@plaird-laptop:~$ jps
19369 org.eclipse.equinox.launcher_1.0.201.R35x_v20090715.jar
18339 org.eclipse.equinox.launcher_1.0.201.R35x_v20090715.jar
19388 Jps

Problem solved. Well…

Caveats

Sadly, this doesn’t solve the problem of identifying which workspace is in use by either. But as long as you remember the order in which you started them, in most cases the pids will be in order.

And the known downside of multiple processes is evident in a ps –ef command:

18325     1 /bin/sh /home/plaird/Apps/eclipse35/eclipse.sh
18326 18325 /home/plaird/Apps/eclipse35/eclipse
18339 18326 /usr/lib/jvm/java-6-sun-1.6.0.16/bin/java equinox.launcher.jar

20111     1 /bin/sh /home/plaird/Apps/eclipse35/eclipse.sh
20112 20111 /home/plaird/Apps/eclipse35/eclipse
20128 20112 /usr/lib/jvm/java-6-sun-1.6.0.16/bin/java equinox.launcher.jar

Which is worse – JPS not listing Eclipse or having more goo in a ps listing?

Random Footnote

I noticed this comment in the JPS docs:

The lvmid is typically, but not necessarily, the operating system's process identifier for the JVM process.

This means that the pid/lvmid reported by JPS cannot always be used in a kill command. Good to know.  

Technorati Tags: java,eclipse