Archive for June, 2009

Départ de Smile (FR)

June 24th, 2009

Ça y est, j’ai officiellement quitté Smile le 19 juin après plus de 5 ans dans la société. Mon adresse email @smile.fr ne fonctionne plus, vous trouverez mon adresse perso sur la page About me.

Pour les Smiliens, les photos de la journée sont disponibles. Le post est protégé : le mot de passe est celui que tout bon Smilien doit connaitre.

Protected: Dernier jour à Smile : les photos

June 23rd, 2009

This post is password protected. To view it please enter your password below:


Fixing ‘could not write file’ issue with Jetty on Windows

June 12th, 2009

Xebia has published a very nice article (Maven, jetty plugin et section mappée – French) explaining how to fix the long-standing locking file issue affecting Jetty / Maven users on Windows.

On this platform, Jetty locks all .js or .css files, making it impossible to change their content while the server is still running. This is a big loss of time because you always have to stop/restart jetty to update one of these files.

Note: this issue does not occur on Linux or Mac OSX so I personnaly don’t really care, but for the ones still running on Windows, the post provides 2 possible fixes :

  • 1 – Changing the connector : this one did not work for us, Jetty was no longer starting (Class not found).
  • 2 – Overriding the defaut web context (webdefault.xml) : it does the trick, Great !

As a result, this is the steps that worked for us :

  • Get webDefault.xml from the jetty jar and add it to your project. Package is org.mortbay.jetty.webapp
  • Change useFileMappedBuffer to false :

    <servlet>
    ...
    <init-param>
    <param-name>useFileMappedBuffer</param-name>
    <param-value>false</param-value>
    </init-param>
    ...
    </servlet>

  • Add this new webDefault.xml to Jetty config :

    ...
    <plugin>
    <groupId>org.mortbay.jetty</groupId>
    <artifactId>maven-jetty-plugin</artifactId>
    <version>6.1.14</version>
    <configuration>
    <webDefaultXml>
    src/main/etc/webdefault.xml
    </webDefaultXml>
    </configuration>
    </plugin>
    ...

  • Restart jetty…. files can be edited. :-)

See original post for additionnal details.

Memory analysis with Eclipse 3.5

June 12th, 2009

Eclipse Galileo (3.5) will be released on June 24, 2009 and comes with a really good and easy-to-use JVM Memory Analyzer.

Memory chart

Memory chart

Here is a quick memory analysis walkthrough :

Creating a heap dump

You can dump the memory of a Java process anytime using jmap which is included in the JDK.

To ensure jmap is working for you, get your java process ID :
ps -Af | grep java

or, if you want to dump eclipse memory :
ps -Af | grep eclipse

Then ask jmap to output a memory summary :

jmap <pid>

Jmap output :
Attaching to process ID 356, please wait...
Debugger attached successfully.
Client compiler detected.
JVM version is 1.5.0_16-133

using thread-local object allocation.
Mark Sweep Compact GC

Heap Configuration:
(...)

If you get an error, take a look at the end of this post for a few tips.

Ok so jmap works for you. Now dump the complete memory in a file :
jmap -heap:format=b <pid>

There is now a file named heap.bin in your current directory.

Installing Memory Analyzer
Start Eclipse, use Help->Install new software… and select Memory Analyzer from the Galileo update site :

Installing Memory Analyzer

Installing Memory Analyzer

Opening the dump

Switch to Memory Analysis perspective

Perspectives : select Memory Analysis

Perspectives : select Memory Analysis


Use File->Open Head Dump… and select heap.bin
Memory summary

Memory summary

You can now digg into your application heap memory and ensure that no objects is using more memory than it should. Memory Analyzer also includes really nice features like an automatic leak search :

Leak suspects report

Leak suspects report

Have fun and catch the leaks :-)

jmap tips
If you have problems running jmap, try the following tips :

  • Be sure to use the jmap binary packaged with the JVM you are running : jmap from a Java 5 JDK will not be able to dump memory from a Java 6 VM : you’ll get this stacktrace :

    Attaching to process ID 704, please wait...
    Exception in thread "main" java.lang.RuntimeException: gHotSpotVMTypes was not initialized properly in the remote process; can not continue
    at sun.jvm.hotspot.HotSpotTypeDataBase.readVMTypes(HotSpotTypeDataBase.java:111)
    at sun.jvm.hotspot.HotSpotTypeDataBase.(HotSpotTypeDataBase.java:68)
    at sun.jvm.hotspot.MacOSXTypeDataBase.(MacOSXTypeDataBase.java:35)
    at sun.jvm.hotspot.bugspot.BugSpotAgent.setupVM(BugSpotAgent.java:560)
    at sun.jvm.hotspot.bugspot.BugSpotAgent.go(BugSpotAgent.java:481)
    at sun.jvm.hotspot.bugspot.BugSpotAgent.attach(BugSpotAgent.java:319)
    at sun.jvm.hotspot.tools.Tool.start(Tool.java:146)
    at sun.jvm.hotspot.tools.JMap.main(JMap.java:128)

  • jmap needs high system privileges. If you can’t attach to a java process with the following error :

    Attaching to process ID 704, please wait...
    attach: task_for_pid(704) failed (5)
    Error attaching to process: Error attaching to process, or no such process

    …, try to use sudo : sudo jmap <pid>. (See Ken Sipe's blog for additional information)

Debug a remote java application with Eclipse

June 12th, 2009

A developper should always be able to start an application in debug mode and run it step by step. While most IDE let you run and debug an application localy in one single click, debugging a remote application needs a few additionnal steps.

These steps are really simple but are usually a blocker for new Java developpers. This is what you need to do in order to run a JVM in debug mode and attach to it from Eclipse IDE :

Just add these options to the JVM :
-Xdebug
-Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=8000

This can be added to a launch script (Tomcat, custom application, …) or using a administration console (Glassfish, …). It’s often enough to look for the java command in your startup script.

The suspend switch makes the JVM wait for a debug connection before resuming application startup :

  • ‘y’ should be used when you have to catch a breakpoint right at the begining of your application
  • ‘n’ should be used when you want to be able run the application as usual and keep the possibility to connect at anytime. Note: running an application in debug mode is slower, even if you don’t attach to it.
  • Then In Eclipse, open and select your project, and use Debug configuration…

    Debug as...

    Debug as... Debug Configurations...

    Create a new debug configuration for a remote Java application :

    Remote Java Application

    Remote Java Application

    Change host value to your remote application host or keep ‘localhost’ if Eclipse and your application both run on the same machine and press Debug.

    Remote connection

    Remote connection

    Your application should immediately resume (if you used suspend=y) and you’ll be able to create breakpoints and use the debug perspective as usual.

    Note : I know there are tons of posts on this topic all across the internet, but I like to have it here too :-)