To make sure I don’t loose the complete text if Adam’s blog gets closed/moved/attacked etc. I have pasted it here below.

Here is a small HOWTO regarding the tools that help find memory leaks.

Note: Use the latest JDK 6, because it has the latest tools, with lots of bugfixes and improvements. All the later examples assume that JDK6′s bin directory is in the PATH.

Step 1. Start the application.

Start the application as you usually do:

java -jar java_app.jar

Alternatively, you could start java with hprof agent. Java will run slower, but the huge benefit of this approach is that the stack traces for created objects will be available which improves memory leak analysis greatly:

java \

-Dcom.sun.management.jmxremote

-Dcom.sun.management.jmxremote.port=9000 \

-Dcom.sun.management.jmxremote.authenticate=false \

-Dcom.sun.management.jmxremote.ssl=false \

-agentlib:hprof=heap=dump,file=/tmp/hprof.bin,format=b,depth=10 \

-jar java_app.jar

When the application is up, perform various actions that you think might lead to memory leaks.

You might use jconsole from JDK 6 to see the memory consumption graph to have a clue whether memory leak is present or not:

jconsole

It will present a dialog with a list of java apps to connect to. Find the one with java_app.jar and connect.

For example, if you open some documents in your app, the memory graph could rapidly go up. If closing the docs and invocation of full garbage collection did not bring the memory back to normal level, there is probably a leak somewhere.

Jconsole allows to invoke full GC providing nice button just for that.

Step 2. Find the application pid.

Find out the application’s process id via:

jps

It will print something like:

15976 java_app.jar

7586 startup.jar

22476 Jps

12248 Main

5437 Bootstrap

In our case the pid is 15976.

Step 3. Dump the heap into file.

Dump heap into the file:

jmap -dump:format=b,file=/tmp/java_app-heap.bin 15976

We just told jmap to dump the heap into /tmp/java_app-heap.bin file, in binary from (which is optimized to work with large heaps). The third parameter is the pid we found in Step 2.

Alternatively, if you started java with hprof agent, you could just use Ctrl-\ on Solaris/Linux or Ctrl-Break on Windows to dump heap into the file, specified in hprof agent arguments.

Step 4. Visualize the heap.

Use jhat tool to visualize the heap:

jhat -J-Xmx326m /tmp/java_app-heap.bin

Jhat will parse the heap dump and start a web server at port 7000

Connect to Jhat server.

Point your browser to:

http://localhost:7000

And start investigating.

Jhat allows you to see what obects are present in the heap, who has references to those objects, etc.

Here are some tips:

* Investigate _instances_, not _classes_

* Use the following URL to see the instances:

http://localhost:7000/showInstanceCounts/

* Use “Reference Chains from Rootset” (Exclude weak refs!!!) to see who’s holding the instance

The text of my post on the formum was:

I recently got a Dell D620 laptop, with a “Intel® PRO/Wireless 3945ABG Network Connection” internal WLAN card.

When I connected, wired, to the FSG, all worked fine.

When I connected WireLess, I could connect to the FSG, got an IP address though DHCP, but there it more-or-less stopped. I could start a browser, and sometimes I could browse some pages (or even only partially). Response times were awfull.

After googling a long time, I found the following article: http://www.intel.com:80/support/wireless/wlan/sb/cs-006205.htm, blaming the firmware of the Access point…

After disabling PSP, by setting powersafe mode to “Max Performance” on my WLAN adapter, all worked again.

Some known projects that use Hudson for their buildmanagement are: NetBeans and GlassFish.

https://hudson.dev.java.net/

On the site, the author of Hudson gives a short summary of the features of Hudson:

Easy installation

If you have a running servlet container (such as Tomcat), installation is as easy as copying a war file into it.

Change set support

Hudson can generate a list of changes made into the build from CVS/Subversion. This is also done in a fairly efficient fashion, to
reduce the load of the repository.

Permanent links to “latest build”/”latest successful build”

Hudson gives you a fixed URL for those, so that they can be easily linked from elsewhere.

RSS/E-mail Integration

Monitor build results by RSS or e-mail to get real-time notifications on failures.

After-the-fact tagging

Builds can be tagged long after builds are completed

JUnit test reporting

JUnit test reports can be tabulated, summarized, and displayed with history information, such as when it started breaking, etc. History trend is plotted into a graph.

Distributed builds

Hudson can distribute build/test loads to multiple computers. This lets you get the most out of those idle workstations sitting beneath developers’ desks.

File fingerprinting

Hudson can keep track of which build produced which jars, and which build is using which version of jars, and so on. This works even for jars that are produced outside Hudson, and is ideal for projects to track dependency.

Plugin Support

Hudson can be extended via 3rd party plugins. You can write plugins to make Hudson support tools/processes that your team uses.

I have used Hudson in practice already, and it is definitely true. there are even a lot of features that are not mentioned, like the great inline documentaion of all features; every field in the webinterface has a online help that can be displayed inline (ajax).

To conclude:

Everyone that is in need of a (new) build system, for any kind of product (not only Java) should consider Hudson.

New Features

• Scripting support
• Database in JVM
• XML and WebServices improvements
• more

Het was een goed georganiseerde dag, met een keur aan binnen- en buitenlandse sprekers.

Agenda
10:-00-10:30 Introduction & JEMS Roadmap update (Kris D’Hooghe en Chris Mills)
Korte update waar een aantal geplande opleverdata de revu passeerden. Alle informatie van dit verhaal is ook te vinden op www.jboss.org (verbaas je ook eens over het grote aantal sub-projecten op de site).

10:30-11:00 JEMS Customer Success Story (Peer van Heeswijk, manager SNS bank)
Peer vertelde een boeiend verhaal over de IT organisatie binnen de SNS bank, waar gekozen is voor voornamelijk open source bouwstenen. Zo is de standaard desktop voorzien van Linux, er wordt geprogrammeerd met Java en (en daar ging het natuurlijk vandaag om) wordt JBoss gebruikt als applicatie server.

11:10-14:00 JBoss ON Training (Greg Hinkle, project leider JBoss ON)
Na een korte koffie pauze begon het praktische gedeelte van de dag. Eerst begon Greg met een theoretisch verhaaltje, om daarna instructies te geven over hoe we de geleverde CD met JBoss moesten installeren. De installatie was volledig beschreven, en de installer was grafisch, toch hadden sommige mensen wat meer moeite dan andere, en kwamen pas heel laat naar de lunch .
Na de lunch vervolgde Greg z’n verhaal met een aantal demootjes van de mooie beheers GUI, en aansluitend mochten wij dan eindelijk ook weer een aantal opdrachtjes uitvoeren. Vervolgens werd monitoring en alerting aangesneden, gevolgd door opdrachten.
De tijd was zo om, en ik moet toegeven dat de beheers interface er gelikt uitziet, en niet alleen dat, hij lijkt ook nog eens heel functioneel.

14:00-15:30 EJB3 and Seam training (Christian Bauer, JBoss)
Seam is een applicatie framework, dat werkt met de nieuwe specs van Java EE 5.0; EJB3.0 / JSF 1.1 / Annotations etc.

From the JBoss website:

Seam introduces the notion of declarative application state management for POJO components. Seam components are stateful and contextual, with a well-defined container-managed lifecycle. This approach helps solve a whole class of bugs and performance problems that plague web applications with non-linear or multi-window navigation.

Na het bestuderen van de slides die ik toegestuurd krijg, zal ik wat meer hierover vertellen.

Al met al was dit een goede afsluiting van mijn werkweek, en een heel mooi begin van mijn vakantie .

Ik ben nog een newbe met bloggen, maar volgens zeggen kan iedereen het

De naam JavaTools voor dit blog komt van het domein dat ik lang geleden gereserveerd heb: JavaTools.nl. Het leuke van zo’n sprekende domeinnaam is dat je die heel goed als package name in je java applicaties kunt gebruiken. In het begin heb ik geprobeerd om een postnuke site bij te houden op die URL, maar al gauw zag ik dat daar zoveel werk in zat, dat ik het eenvoudigweg niet naast mijn bestaande werk kon doen.