JBoss Clustering 4.2

Easiest way is use the 'all' server instance that already is configured for clustering in jboss.

If you have not used the 'all' instance then copy these three files from 'all' server to your server instance and it should work:

• cluster-service.xml (all/deploy directory)
  
• jbossha.jar (all/lib directory)
• jgroups.jar (all/lib directory)
  

JBoss Monitoring and Performance

JBoss page how to slim your JBoss AS
Tuning JBoss on linux article

Memory and thread Montoring (see chapter 10 in JBoss 4.2 Server configuration guide)

MBean
In the JMX-console: jboss.system:type=ServerInfo MBean (view interesting attributes like FreeMemory, ActiveThreadCount etc.)

Checklist
(Read more about this in the book "JBoss Seam - Simplicity and Power beyond Java EE")
1. Use "Call by reference" (see JBoss Reference)
2. Optimize JVM (start using the -server option)
- Give at least 75 percent of the physical RAM to the JVM ( JAVA_OPT in bin/run.sh)
- set JAVA_OPTS=%JAVA_OPTS% -Xms1024m -Xmx1024m -XX:PermSize=256m -XX:MaxPermSize=512
- Using the same value for Xms and Xmx will force JVM to use specified value (in this case 1GB)
- -Xms2g and -Xmx2g would force JVM use 2G of RAM for example
3. Garbage Collector (use parallel GC) or what might be best for you JVM/application
- Run parallel GC
set JAVA_OPTS=%JAVA_OPTS% -XX:+UseParallelGC -XX:+UseParallelOldGC
4. Reduce logging (see JBoss page how to slim your JBoss AS)
5. Tuning the HTTP Thread Pool (see JBoss page how to slim your JBoss AS)
6. Client- or Server-Side State Saving (really depends on your application and RAM vs. Mhz)
There are more things you can do like using Second-Level Cache and Clustering.

Flying Saucer renderer in JBoss Seam Fix

Used the iText and The Flying Saucer xhtml renderer to generate pdf's in my JBoss Seam application.

Problem: Everything worked fine. A pdf was generated in my app but the application context was somehow corrupt after the pdf generation and I could not continue using the app unless I redeployed it on JBoss AS again. I noticed that this happened after I had instanciated the org.xhtmlrenderer.pdf.ITextRenderer.

Found the fix for this in the JBoss Seam forum (thanks Calvin, you saved my day :)).

------------------------------------------------------------------------
Here's a fix for the problem. Set this system property before instantiating your first instance of ITextRenderer:

Code:

System.setProperty("xr.util-logging.loggingEnabled", "false");

The problem seems to be caused by Flying Saucer reconfiguring the log manager by calling LogManager.readConfiguration. Flying Saucer shouldn't really be doing this because it blows away any existing log configuration, but on the other hand it's odd that Seam (or maybe JBoss?) behaves this way when logging is reconfigured.
--Calvin
----------------------------------------------------------------------------
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4106412#4106412

JBoss Seam debug info

Enable/disable seam debug page and faclet debug

Seam - components.xml (debug = ture/false)

Facelets - web.xml (facelets.DEVELOPMENT = true/false)

Entity Inheritance

• Java EE API
  
• Creating Entity Objects for SINGLE_TABLE Inheritance Type
• Creating Entity Objects for JOINED Inheritance Type
• Creating Entity Objects for TABLE_PER_CLASS Inheritance Type
• BEA - 12.6. Inheritance

Java EE load balancing, clustering

• JBoss application server 4.2.2 clustering guide
  
• J2EE clustering with JBoss
  
• Java Performance Tuning
• Pure load balancer
  

Design Patterns

• Java Design Patterns Reference and Examples

Transactions (EJB3)

Transactions in EJB3 and Seam

• ACID
• Put all transactions in your EJBs (not in servlets)
  
• Container or Bean Managed (default in Seam)
  
• Container-managed-transactions (CMTs) preferred in Java EE. The Java EE container will handle comitting, rolling back, starting the transaction, etc. (no coding for the transactions).
  
• 6 types of transactions to choose from (default is REQUIRED)
  
• MANDATORY
• REQUIRED
• REQUIRES_NEW
• SUPPORTS
• NOT_SUPPORTED
• NEVER
• Example: Set this annotation before a method to use a transaction independent of an already-active transaction. Will attempt to commit in the end of the method.

  @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
     public void addUser(User user) {
         em.persist(user);
     }

• Bean-managed transactions (BMTs) allows a much more fine-grained control of transactions. (It is recommended to not use BMTs unless you cannot achieve the goals you are looking for using the CMT option.