Tuesday, August 25, 2009

java.awt.HeadlessException or X11 display

You develop an application in Java which uses AWT on Windows platform. Deploy the build in Unix box and when you hit the URL of the web application only to find that the charts, barcodes etc., are not displayed on the page.

Check the logs and you will see some Exception related to X11 display variable/HeadlessException. This happens when there is no X11 service running.

When you get errors like: java.awt.HeadlessException: No X11 DISPLAY variable was set, but this program performed an operation which requires it

Or, any other error related to X11 or graphics display.

Steps to set the DISPLAY variable:

1) Login with root privileges. This is to ensure that all the DISPLAY settings are common for all the privileges/profiles within root.

2) Execute this script: startx &

This will run the startx command in the background. The startx command is an easy way to start an X session if you're working on a single computer or boot Linux to runlevel 3 mode (X11, multiuser and networking enabled). There are other ways to start X. The startx command is a handy shell script that will pass on command-line options to the X server for your X sessions. The startx command is typically used to pass starting color-depth information to the X server, as well as to find client commands or options to run for the session (usually your .xinitrc file in your home directory).

3) Execute this script to set the DISPLAY variable: export DISPLAY=localhost:0.0

This sets and Environment variables called DISPLAY. EVs store useful information for programs defaults or system state. If you look at your EV you will see a variable called "DISPLAY" this variable stores the address for X clients to connect to. These addresses are in the form: hostname:displaynumber.screennumber

4) Execute this command: xhost +

The xhost program is used to add and delete host (computer) names or user names to the list of machines and users that are allowed to make connections to the X server. This provides a rudimentary form of privacy control and security.

* xhost + hostname: Adds hostname to X server access control list.

* xhost - hostname: Removes hostname from X server access control list.

* xhost + : Turns off acccess control (all remote hosts will have access to X server)

* xhost - : Turns access control back

Once this is done, you can see all graphic related charts and images come up in your application.

java.lang.OutOfMemoryError: PermGen space

Every time we make a new build, we redeploy it, and after a few such redeployments it throws this error.

And we need to restart JBOSS.

As we are seeing this error very frequently, I had googled it and found some information on this.

Here are the links to this information.

These links also say that after a few redeployments, JBOSS console shows up this error.

http://blog.yannis-lionis.gr/?p=8

http://www.freshblurbs.com/explaining-java-lang-outofmemoryerror-permgen-space

http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html#1.1.%20Generations|outline

Excerpt from links:

In Sun JVM, garbage-collection of Java Heap is managed in generations (memory segments holding objects of different ages- Young Generation, Tenured Generation and Permanent Generation). Garbage collection algorithms in each generation are different.

The permanent generation holds data needed by the virtual machine to describe objects that do not have equivalence at the Java language level. For example objects describing classes and methods are stored in the permanent generation.

Applications with large code-base can quickly fill up this segment of the heap which will cause java.lang.OutOfMemoryError: PermGen

We can increase the PermGen (Permanent Generation) size in JVM, but this just delays the error and cannot get rid of it.

To tackle this, posts suggest two options:

  1. Restart the JBOSS every time we redeploy.
  2. Change the Sun JVM to some other JVM.

Links also suggests JRockit JVM as it doesn’t have a PermGen area and can never throw this error.