DraK's Klog

Configuring a JBoss cluster is tedious because you need multiple machines, you need to configure multiple files on different machines, multicast, ips, shares, network interfaces and etc ... In order to make it easier to test things when working with JBoss clusters, here are a few tips.

First of all, use a virtual environment ! I use VMware Workstation on my development laptop (with virtual ip 192.168.208.2) and configure two debian virtual machines v1 and v2 on a NAT virtual network (192.168.208.x) with DHCP activated. I use a NAT virtual network so that the debian virtual machines can apt-get update from the internet through the dev machine.

I only configure one virtual machine (J1) with java and samba then copy and paste it in order to obtain the second virtual machine J2.

To avoid having multiple configuration files around, I find it convenient to centralize the whole JBoss directory in a shared folder on my windows development machine. I use c:\jboss shared on \\192.168.208.2\jboss in read only mode, I explain why the read only mode a bit later.

I then mount it using smbfs on each virtual JBoss node. It can be automated by adding the following line to your /etc/fstab:

//192.168.208.2/jboss /mnt/jboss smbfs ro,username=yourname,password=yourpasswd 0 0

The shared JBoss configuration must absolutely be mounted read only because it will be used by multiple JBoss instances which must not concurrently modify the same files.

JBoss needs additional configuration here because by default, JBoss creates 4 working directories under the server configuration directory server/all/:

• log: used by log4j and configrued in conf/log4j.xml
• data: used by hsqldb (i think)
• work: used by tomcat
• tmp: used by the jboss micro kernel

Those directories will actually be used in read write mode so we must tell JBoss to use some other directory, specific to each virtual node for its write needs. I use /var/local/jboss.

JBoss allows to do just that with the following property:

jboss.server.home.dir=/var/local/jboss

On the command line, you would pass the property that way:

./bin/run.sh -Djboss.server.home.dir=/var/local/jboss

But to avoid having to remember that and to take advantage of the configuration being centralized on the shared directory on the dev machine, edit the c:\jboss\bin\run.conf file and add the following line at the end:

JAVA_OPTS="$JAVA_OPTS -Djboss.server.home.dir=/var/local/jboss"

Now, you're setup, on each virtual node, you can start the jboss instance directly from the shared mount:

/mnt/jboss/bin/run.sh -c all

The shared /mnt/jboss directory structure will not be modified, all working files will be put in node specific /var/local/jboss sub directories !

Finally, just as you did for the conf/run.conf file, to modify the configuration of cluster nodes, just edit the files directly using the windows editor of your choice under the c:\jboss directory ... All cluster nodes will use those files. Dependencing on whether they are hot deployed or not, you may need to restart all instances of course.

Btw, if someone knows how to restart all nodes in the cluster partition, the tip would be helpfull

Enjoy !

Article complet sur JBoss Seam.

Concis et pertinent.

Yet another profiler ? Well not exactly, this profiler has the main benefit of exposing a Java API and unit testing has been part of its scope since the beginning. It is specifically handy to unit test memory leaks. The whole memory information can be queried using the Java API which means that you can assert anything on the state of the memory given that you know what to assert

Very handy for complexes memory tests.

Il était impossible (à ma connaissance) jusqu'à récemment d'utiliser une console JMX graphique avec JBossAS 4. En effet, d'une part le support JBossAS 4 de MC4J est très approximatif et d'autre part JBoss ne supportera la JSR 160 qu'à partir de sa version 5, ce qui nous laissait sans autre possibilité que d'utiliser la console JMX HTML fournie avec JBoss.

Depuis la version 4.0.3 de JBoss, celui-ci est néanmoins compatible avec JConsole, la console JMX fournie avec le JDK5. On va peut-être enfin pouvoir utiliser une console JMX graphique avec JBoss (en l'occurence celle du JDK5) !

Cette solution n'est cependant pas parfaite, car elle se limite aux installations de JBoss 4.0.3 sur JDK5, ce qui ne court pas vraiment les rues chez les clients ...

Cette page explique comment afficher simultanément les MBeans Java et JBoss.

If you are trying to map Hibernate Objects into JBoss TreeCache regions, the translation between names is not exactly obvious.

Bonne explication des capacités de clustering de JBoss.

Chosen Software for the Application Layer: JBoss
Why JBoss?



JBoss is currently a very popular Open Source J2EE Application server. It has very easy configuration of Clustering, with features such as auto discovery of the IP address from the clients, which allows fail-over to a new machine when the one running the JNDI directory fails. The JNDI directory in a JBoss Cluster directs requests to the machine in the cluster "best suited" to handle the request, and takes machines out of the cluster when the machine appears to be failing. With the "farming" feature in a JBoss Cluster, it is possible to deploy updates across all machines in the cluster. A JBoss Cluster supports hot application deployment.

Un document intéressant sur la gestion du classloading dans JBoss. Cette considération n'est malheureusement pas couverte par la spécification J2EE 1.4, du coup chaque serveur d'application le fait à sa sauce.