The performance of Java Enterprise applications is the sum of a set of components including the Java Virtual Machine configuration, the application server configuration (in our case, JBoss AS), the application code itself, and ultimately the operating system. This
book will show you how to apply the correct tuning methodology and use the tuning tools that will help you to monitor and address any performance issues.

By looking more closely at the Java Virtual Machine, you will get a deeper understanding of what the available options are for your applications, and how their performance will be affected. Learn about thread pool tuning, EJB tuning, and JMS tuning, which are crucial parts of enterprise applications.

The persistence layer and the JBoss Clustering service are two of the most crucial elements which need to be configured correctly in order to run a fast application. These aspects are covered in detail with a chapter dedicated to each of them.

Finally, Web server tuning is the last (but not least) topic covered, which shows how to configure and develop web applications that get the most out of the embedded Tomcat web server.

What This Book Covers

Chapter 1, Performance Tuning Concepts, discusses correct tuning methodology and how it fits in the overall software development cycle.

Chapter 2, Installing the Tools for Tuning, shows how to install and configure the instruments for tuning, including VisualVM, JMeter, Eclipse TPTP Platform, and basic OS tools.

Chapter 3, Tuning the Java Virtual Machine, provides an in-depth analysis of the JVM heap and garbage collector parameters, which are used to start up the application server.

Chapter 4, Tuning the JBoss AS, discusses the application server’s core services including the JBoss System Thread Pool, the Connection Pool, and the Logging Service.

Chapter 5, Tuning the Middleware Services, covers the tuning of middleware services including the EJB and JMS services.

Chapter 6, Tuning the Persistence Layer, introduces the principles of good database design and the core concepts of Java Persistence API with special focus on JBoss‘s implementation (Hibernate).

Chapter 7, JBoss AS Cluster Tuning, covers JBoss Clustering service covering the lowlevel details of server communication and how to use JBoss Cache for optimal data replication and caching.

Chapter 8, Tomcat Web Server Tuning, covers the JBoss Web server performance tuning including mod_jk, mod_proxy, and mod_cluster modules.

Chapter 9, Tuning Web Applications on JBoss AS, discusses developing fast web applications using JSF API and JBoss richfaces libraries.

	6th Circle of Hell: Heresy. This circle houses administrators who accurately set up
	a cluster to use Buddy Replication. Without caring about steady sessions.

Clustering allows us to run applications on several parallel instances (also known as cluster nodes). The load is distributed across different servers, and even if any of the servers fails, the application is still accessible via other cluster nodes. Clustering is crucial for scalable Enterprise applications, as you can improve performance by simply adding more nodes to the cluster.

In this chapter, we will cover the basic building blocks of JBoss Clustering with the following schedule:

• A short introduction to JBoss Clustering platform

• In the next section we will cover the low level details of the JGroups library, which is used for all clustering-related communications between nodes

• In the third section we will discuss JBoss Cache, which provides distributed cache and state replication services for the JBoss cluster on top of the JGroups library

Introduction to JBoss clustering

Clustering plays an important role in Enterprise applications as it lets you split the load of your application across several nodes, granting robustness to your
applications. As we discussed earlier, for optimal results it’s better to limit the size of your JVM to a maximum of 2-2.5GB, otherwise the dynamics of the
garbage collector will decrease your application’s performance.

Combining relatively smaller Java heaps with a solid clustering configuration can lead to a better, scalable configuration plus significant hardware savings.

The only drawback to scaling out your applications is an increased complexity in the programming model, which needs to be correctly understood by aspiring architects.

JBoss AS comes out of the box with clustering support. There is no all-in-one library that deals with clustering but rather a set of libraries, which cover different kinds of aspects. The following picture shows how these libraries are arranged:

On the other hand, HAPartition is an abstraction built on top of a JGroups Channel that provides support for making and receiving RPC invocations from one or more cluster members. For example HA-JNDI (High Availability JNDI) or HA Singleton (High Availability Singleton) both use HAPartition to share a single Channel and multiplex RPC invocations over it, eliminating the configuration complexity and runtime overhead of having each service create its own Channel. (If you need more information about the HAPartition service you can consult the JBoss AS documentation http://community.jboss.org/wiki/jBossAS5ClusteringGuide.). In the next section we will learn more about the JGroups library and how to configure it to reach the best performance for clustering communication.

Configuring JGroups transport

Clustering requires communication between nodes to synchronize the state of running applications or to notify changes in the cluster definition. JGroups (http://jgroups.org/manual/html/index.html) is a reliable group communication toolkit written entirely in Java. It is based on IP multicast, but extends by providing reliability and group membership.

Member processes of a group can be located on the same host, within the same Local Area Network (LAN), or across a Wide Area Network (WAN). A member can be in turn part of multiple groups. The following picture illustrates a detailed view of JGroups architecture:

	In theory, you could configure every service to bind to a
	different Channel. However this would require a complex thread
	infrastructure with too many thread context switches. For this
	reason, JBoss AS is configured by default to use a single Channel
	to multiplex all the traffic across the cluster.

The Protocol stack contains a number of layers in a bi-directional list. All messages sent and received over the channel have to pass through all protocols. Every layer may modify, reorder, pass or drop a message, or add a header to a message. A fragmentation layer might break up a message into several smaller messages, adding a header with an ID to each fragment, and re-assemble the fragments on the receiver’s side.

The composition of the Protocol stack (that is, its layers) is determined by the creator of the channel: an XML file defines the layers to be used (and the parameters for each layer).

	Knowledge about the Protocol stack is not necessary when
	just using Channels in an application. However, when an
	application wishes to ignore the default properties for a Protocol
	stack, and configure their own stack, then knowledge about what
	the individual layers are supposed to do is needed.

In JBoss AS, the configuration of the Protocol stack is located in the file, \deploy\cluster\jgroups-channelfactory.sar\META-INF\jgroupschannelfactory-stacks.xml.

The file is quite large to fit here, however, in a nutshell, it contains the following basic elements:

	A multicast UDP socket can send and receive datagrams from multiple
	clients. The interesting and useful feature of multicast is that a client
	can contact multiple servers with a single packet, without knowing the
	specific IP address of any of the hosts.

Next to the UDP transport configuration, three protocol stacks are defined:

• udp: The default IP multicast based stack, with flow control

• udp-async: The protocol stack optimized for high-volume asynchronous RPCs

• udp-sync: The stack optimized for low-volume synchronous RPCs

Thereafter, the TCP transport configuration is defined . TCP stacks are typically used when IP multicasting cannot be used in a network (for example, because it is disabled) or because you want to create a network over a WAN (that’s conceivably possible but sharing data across remote geographical sites is a scary option from the performance point of view).

You can opt for two TCP protocol stacks:

• tcp: Addresses the default TCP Protocol stack which is best suited to high-volume asynchronous calls.

• tcp-async: Addresses the TCP Protocol stack which can be used for low-volume synchronous calls.

	If you need to switch to TCP stack, you can simply include the following
	in your command line args that you pass to JBoss:
	-Djboss.default.jgroups.stack=tcp
	Since you are not using multicast in your TCP communication, this
	requires configuring the addresses/ports of all the possible nodes in the
	cluster. You can do this by using the property -Djgroups.tcpping.
	initial_hosts. For example:
	-Djgroups.tcpping.initial_hosts=host1[7600],host2[7600]

Ultimately, the configuration file contains two stacks which can be used for optimising JBoss Messaging Control Channel (jbm-control) and Data Channel (jbm-data).

How to optimize the UDP transport configuration

The default UDP transport configuration ships with a list of attributes, which can be tweaked once you know what they are for. A complete reference to the UDP transport configuration can be found on the JBoss clustering guide (http://docs. jboss.org/jbossclustering/cluster_guide/5.1/html/jgroups.chapt. html); for the purpose of our book we will point out which are the most interesting ones for fine-tuning your transport. Here’s the core section of the UDP transport configuration:

The biggest performance hit can be achieved by properly tuning the attributes concerning buffer size (ucast_recv_buf_size, ucast_send_buf_size, mcast_recv_buf_size, and mcast_send_buf_size ).

	<UDP
		singleton_name="shared-udp"
		mcast_port="${jboss.jgroups.udp.mcast_port:45688}"
		mcast_addr="${jboss.partition.udpGroup:228.11.11.11}"
		tos="8"
		ucast_recv_buf_size="20000000"
		ucast_send_buf_size="640000"
		mcast_recv_buf_size="25000000"
		mcast_send_buf_size="640000"
		loopback="true"
		discard_incompatible_packets="true"
		enable_bundling="false"
		max_bundle_size="64000"
		max_bundle_timeout="30"
		. . . .
	/>

As a matter of fact, in order to guarantee optimal performance and adequate reliability of UDP multicast, it is essential to size network buffers correctly. Using inappropriate network buffers the chances are that you will experience a high frequency of UDP packets being dropped in the network layers, which therefore need to be retransmitted.

The default values for JGroups’ UDP transmission are 20MB and 64KB for unicast transmission and respectively 25MB and 64KB for multicast transmission. While these values sound appropriate for most cases, they can be insufficient for applications sending lots of cluster messages. Think about an application sending a thousand 1KB messages: with the default receive size, we will not be able to buffer all packets, thus increasing the chance of packet loss and costly retransmission.

Monitoring the intra-clustering traffic can be done through the jboss.jgroups domain Mbeans. For example, in order to monitor the amount of bytes sent and received with the UDP transmission protocol, just open your jmx-console and point at the jboss.jgroups domain. Then select your cluster partition. (Default the partition if you are running with default cluster settings). In the following snapshot (we are including only the relevant properties) we can see the amount of Messages sent/received along with their size (in bytes).

The advantage of using this approach is that the transport protocol would send bundled queued messages in one single larger message. Message bundling can have significant performance benefits for channels using asynchronous high volume messages (for example, JBoss Cache components configured for REPL_ASYNC. JBoss Cache will be covered in the next section named Tuning JBoss Cache).

On the other hand, for applications based on a synchronous exchange of RCPs, the introduction of message bundling would introduce a considerable latency so it is not recommended in this case. (That’s the case with JBoss Cache components configured as REPL_SYNC).

How to optimize the JGroups’ Protocol stack

The Protocol stack contains a list of layers protocols, which need to be crossed by the message. A layer does not necessarily correspond to a transport protocol: for example a layer might take care to fragment the message or to assemble it. What’s important to understand is that when a message is sent, it travels down in the stack, while when it’s received it walks just the way back.

For example, in the next picture, the FLUSH protocol would be executed first, then the STATE, the GMS, and so on. Vice versa, when the message is received, it would meet the PING protocol first, them MERGE2, up to FLUSH.

	<stack name="udp"
		description="Default: IP multicast based stack, with flow
	control.">
		<config>
			<PING timeout="2000" num_initial_members="3"/>
			<MERGE2 max_interval="100000" min_interval="20000"/>
			<FD_SOCK/>
			<FD timeout="6000" max_tries="5" shun="true"/>
			<VERIFY_SUSPECT timeout="1500"/>
			<pbcast.NAKACK use_mcast_xmit="false" gc_lag="0"
				retransmit_timeout="300,600,1200,2400,4800"
				discard_delivered_msgs="true"/>
			<UNICAST timeout="300,600,1200,2400,3600"/>
			<pbcast.STABLE stability_delay="1000"
				desired_avg_gossip="50000"
				max_bytes="400000"/>
			<pbcast.GMS print_local_addr="true" join_timeout="3000"
				shun="true"
				view_bundling="true"
				view_ack_collection_timeout="5000"/>
			<FC max_credits="2000000" min_threshold="0.10"
				ignore_synchronous_response="true"/>
			<FRAG2 frag_size="60000"/>
			<pbcast.STATE_TRANSFER/>
			<pbcast.FLUSH timeout="0"/>
		</config>
	</stack>

The following table will shed some light on the above cryptic configuration:

The FC protocol, for example can be used to adapt the rate of messages sent with the rate of messages received. This has the advantage of creating an homogeneous rate of exchange, where no sender member overwhelms receiver nodes, thus preventing potential problems like filling up buffers causing packet loss. Here’s an example of FC configuration:

	<FC max_credits="2000000"
		min_threshold="0.10"
		ignore_synchronous_response="true"/>

The message rate adaptation is done with a simple credit system in which each time a sender sends a message a credit is subtracted (equal to the amount of bytes sent). Conversely, when a receiver collects a message, a credit is added.

• max_credits specifies the maximum number of credits (in bytes) and should obviously be smaller than the JVM heap size

• min_threshold specifies the value of min_credits as a percentage of the max_credits element

• ignore_synchronous_response specifies whether threads that have carried messages up to the application should be allowed to carry outgoing messages back down through FC without blocking for credits

The following image depicts a simple scenario where HostA is sending messages (and thus its max_credits is reduced) to HostB and HostC, which increase their max_credits accordingly.

	Besides JGroups, some network interface cards (NICs) and switches
	perform ethernet flow control (IEEE 802.3x), which causes overhead
	to senders when packet loss occurs. In order to avoid a redundant flow
	control, you are advised to remove ethernet flow control. For managed
	switches, you can usually achieve this via a web or Telnet/SSH interface.
	For unmanaged switches, unfortunately the only chance is to hope that
	ethernet flow control is disabled, or to replace the switch.
	If you are using NICs, you can disable ethernet flow control by means of
	a simple shell command, for example, on Linux with the ethtool:
	/sbin/ethtool -A eth0 autoneg off tx on rx on
	If you want simply to verify if ethernet flow control is off:
	/sbin/ethtool -a eth0

One more thing you must be aware of is that, by using JGroups, cluster nodes must store all messages received for potential retransmission in case of a failure. However, if we store all messages forever, we will run out of memory. The distributed garbage
collection service in JGroups periodically removes messages that have been seen by all nodes from the memory in each node. The distributed garbage collection service is configured in the pbcast.STABLE sub-element like so:

	<pbcast.STABLE stability_delay="1000"
		desired_avg_gossip="5000"
		max_bytes="400000"/>

The configurable attributes are as follows:

• desired_avg_gossip: Specifies the interval (in milliseconds) between garbage collection runs. Setting this parameter to 0 disables this service.

• max_bytes: Specifies the maximum number of bytes to receive before triggering a garbage collection run. Setting this parameter to 0 disables this service.

	You are advised to set a max_bytes value if you have a 	high-traffic cluster.

JBoss Tools Palette Toolbar

Note that on the top right corner of the palette, we have a toolbar made of three buttons (as shown in the following screenshot). They are (from left to right):

• Palette Editor
• Show/Hide
• Import

Palette Editor

Clicking on the Palette Editor icon will display the Palette Editor window (as shown in the following screenshot), which contains groups and subgroups of tags that are currently supported. Also, from this window you can create new groups, subgroups,
icons, and of course, tags—as you will see in a few moments.

1. Select from the left panel the tag that you want to modify (for example, the <div> tag from the HTML | Block subgroup, as shown in the previous screenshot).
2. In the right panel, click on the row from the value column that corresponds to the property that you want to modify (the name column).
3. Make the desirable modification(s) and click the OK button for confirming it (them).

Creating a set of icons

The Icons node from the left panel allows you to create sets of icons and import new icons for your tags. To start, you have to right-click on this node and select the Create | Create Set option from the contextual menu (as shown in the following screenshot).

Importing an icon

You can import a new icon in any set of icons by right-clicking on the corresponding set and selecting the Create | Import Icon option from the contextual menu (as shown in the following screenshot):

Creating a group of tag libraries

As you can see, the JBoss Tools Palette has a consistent default set of groups of tag libraries, like HTML, JSF, JSTL, Struts, XHTML, etc. If these groups are insufficient, then you can create new ones by right-clicking on the Palette node and selecting the Create | Create Group option from the contextual menu (as shown in the following screenshot).

Creating a tag library

Now that we have created a group, it’s time to create a library (or a subgroup). To do this, you have to right-click on the new group and select the Create Group option from the contextual menu (as shown in the following screenshot).

Creating a new tag

After you have created a tag library, it is time to place your first tag in it. To do this, you have to right-click on the tag library and select the Create | Create Macro option from the contextual menu (as shown in the following screenshot).

• The tag Name (mandatory)—it is displayed in Tools Palette
• An Icon (optional)
• Start Text of the tag (optional)
• End Text of the tag (optional)
• Automatically Reformat Tag Body (mandatory).

<div style="overflow: auto; width: 270px; height: 375px; padding: 0px; margin: 0px;">
<table cellspacing="0" cellpadding="2"><colgroup><col width="270" /></colgroup>
<tbody>
<tr>
<td valign="top" nowrap="nowrap" width="270"></td>
</tr>
</tbody>
</table>
</div>

For this, we fill up the Add Palette Macro as seen in the previous screenshot.

Note that you can delete a tag (only tags created by the user) by selecting the Delete option from the contextual menu that appears when you right-click on the chosen tag.

As you can see in the previous screenshot, there is no section for describing your tag definition, syntax, attributes, etc. For that you can click on the tag name and modify the description row from the right panel of the Palette Editor or you can right-click on the tag name and select the Edit option from the contextual menu. This will open the Edit window that contains a Description section as you can see in the following screenshot:

<table width="300">
<tbody>
<tr>
<td><span style="color: olive;">
<strong>Name:</strong> </span> <code>
Scrollable table </code>

<span style="color: olive;"> <strong>Syntax:</strong> </span> <code>

 </code></td>
</tr>
</tbody>
</table>
<span style="color: olive;"><strong>Atributes:</strong></span>
CSS and table specific attributes</code>

Now, closing t he Palette Editor by clicking the OK button will automatically add the new group, the tag library, and the tag into the JBoss Tools Palette as shown in the following figure (note the description that appears on mouse over).

Show/Hide

As the name sug gests, this feature allows us to customize the number of groups displayed in the palette. By default, the palette shows only five groups, but we can add or remove groups by clicking on this button, which displays the window as shown in the following screenshot.

Importing third-party tag libraries

A great facility of JBoss Tools Palette is the ability to import third party tag libraries. This can be done using the Import button, which opens the Import Tags from TLD file window as shown in the following screenshot.

Using tags in text files

In this section, w e will discuss inserting tags from the Palette into our text files. This is a very simple task that consists of the following steps:

1. Navigate through the Palette until you see the tag that will be inserted.
2. Click on this tag as you click on any button.
3. If the tag has attributes, then you will see the Insert Tag window that allows you to customize the values of these attributes (the following screenshot represents the Insert Tag window for the <table> tag that can be found in HTML group, Table tag library). Note that if the selected tag doesn’t have any attributes to be set, then this step will be skipped and the tag will be
   inserted into your page.
4. After you have set the values of the attributes, simply click the Finish button. This action will automatically insert the chosen tag into your page. For example, in the following screenshot you can see the effect of inserting the <mytable> tag, created in the Create a new tag section, into an empty HTML page.
5.  If you followed Chap ter 2, then now you should have an empty project named test. Expand the test | WebContent node, right-click on it, and select New | Other option. In the New window, expand Web node and select HTML leaf. Type example
   (without the .html extension) in the File name field and click on the Finish button. Now, you have the shown example.html page and you can try to add our tag to it. Also, you can play with other tags to get used to them! In the following chapters
   this will be no more a task, it will simply be routine.

Summary

In this chapter, you have learnt how to use and customize the JBoss Tools Palette for speeding up the development process of different kinds of pages, like JSP, HTML, XHTML, etc. This will be an important skill to possess in the following chapters when we will develop projects that contain many such pages.

The above diagram shows the logical architecture of the components. Any
operating system (here we are using windows xp)along with Jboss application server forms the foundation. jUDDI web application is deployed in jBoss application server. Web Services are registered in the jUDDI web application.

Configuring jUDDI with JBOSS and MySQL

UDDI needs persistent storage as mentioned in above section. Here we use MySQL for persistents.

Step 1:

Download MySQL-5.0.26 and install MySQL. Set the root password to password.

Step 2:

Install Jboss application server. Jboss version 4.0.5 is used for investigation.

Step 3:

MySQL driver installation: Download the corresponding drivers from the Internet and place it in <jboss_home>\server\default\lib folder. Driver used here is mysql-connector-java-5.0.4-bin.jar.
</jboss_home>

Step 4:

jUDDI Deployment:

• Download JUDDI version 0.9rc4
• Unzip the file to some folder, say JUDY. There will be a folder inside the unzipped package named juddi. This folder has the folder structure as of web applications. Copy the folder and place it inside
  <JBOSS_HOME>\server\default\deploy. Rename the folder to
  juddi.war.
• Inside JUDY where we have unzipped juddi download there is a folder called “sql”. There we can find the sql scripts for many databases. In that we do have sql script for creating juddi schema for MySQL. Run that script in installed MySQL and create the database and the tables.
• Create juddi.xml: Create a file named juddi.xml in the folder <JBOSS_HOME>\server\default\conf and with in that copy and past the following code. The password in the following code should be set to the MySQL database password.

  <? Xml version="1.0" encoding="ISO-8859-1"?>
  <!DOCTYPE weblogic-web-app PUBLIC "-//BEA Systems, Inc.//DTD Web Application
  6.0//EN"  "http://www.bea.com/servers/wls600/dtd/weblogic-web-jar.dtd">
  <Context path="/juddi" docBase="juddi" debug="5" reloadable="true"
  crossContext="true">
  <Logger className="org.apache.catalina.logger.FileLogger"
  prefix="localhost_juddiDB_log" suffix=".txt" timestamp="true"/>
  <Resource name="jdbc/juddiDB" auth="Container" type="javax.sql.DataSource"
  maxActive="100" maxIdle="30" maxWait="10000" username="juddi"
  password="password" driverClassName="org.gjt.mm.mysql.Driver"
  url="jdbc: mysql://localhost:3306/juddi?autoReconnect=true" />
  </Context>
  

• Edit juddi.properties file located at <JBOSS_HOME>\server\default\deploy\juddi.war\web-inf\juddi.properties. Match the email address used with in the insert-publisher.sql. This should match the domine name used for the email address with in JUDDI’s insert-publisher.sql file

  <code>juddi.operatorEmailAddress = yourEmail@aDomain.com</code>

• Create juddi-da.xml and place it in <JBOSS_HOME>\server\default\deploy. Copy the following code to it and save the file.

  <?xml version="1.0" encoding="UTF-8"?>
  <datasources>
  <local-tx-datasource>
  <jndi-name>juddiDB</jndi-name>
  <connection-url>jdbc:mysql://localhost:3306/juddi</connection-url>
  <driver-class>com.mysql.jdbc.Driver</driver-class>
  <user-name>root</user-name>
  <password>password</password>
  <min-pool-size>1</min-pool-size>
  <max-pool-size>50</max-pool-size>
  </local-tx-datasource>
  </datasources>
  

• Edit juddi-user.xml file located at <JBOSS_HOME>\server\default\deploy\juddi.war\web-inf\juddi-user.xml and change the password for the user juddi to MySQL root password (i.e., password)
• Run Jboss. Enter the URL http://<hostname>:8080/juddi/. We will get the juddi home page.
  Click on validate link. If there are any errors found in the validation page, Please follow all the steps above and validate again. If there are no errors then it means juddi is configured successfully.

Once jUDDI is configured, its time to publish Web Service Description Language(WSDL). To publish there are some ways to do so. One of the way is to use the jUDDI API’s and write a CLI application to register the service in the
registory. We also have some GUI UDDI tools through which we can register the services. These informations are not in the scope of this document.

References

• http://ws.apache.org/juddi/
• http://www.uddi.org/

Conclusion

Though this document stops with jUDDI configuration, there is a lot to
learn and not covered under this document. we will conclude this
document saying UDDI registry will help the feature B2B Internet web
applications to a great extent to solve most of their current problems.