JBOSS EAP 6

What are the new features in JBOSS 7 ?

Many new capabilities compared to previous versions
Fully functional web-based administrative console
Robust scripting language to script administrative tasks
New classloading architecture (JBoss Modules)
New server folder structure
"Domains" to manage multiple servers from a single control point
Major reductions in startup time and memory footprint

Architecture

AS 7 core is based on JBoss Modules

Small, modular, class loading & execution environment for Java
Responsible for loading libraries into the server
Non-hierarchical class-loading architecture with application isolation, "on-demand"
loading of modules and dependencies
Very fast loading, Helps eliminate "Jar Hell"
Modular Service Container (MSC) Basis of server kernel
Lightweight services, with highly-concurrent dependency resolution allowing concurrent
starting of services
Non-critical services can be started on-demand
Dynamic Module Representation (DMR)
De-typed management API
Forms basis for the CLI (Command line interface)

Subsystems configure available services in AS 7

Each one is a set of capabilities added to the server
For example, the Web container is added as a subsystem
XML configuration files configure the subsystems in a server
A profile is a named set of subsystems
Along with the details of each subsystem's configuration
Profiles are configured in the main server configuration file
User deployments are modules
Some dependencies are automatically set up (e.g. on JEE)
User can set up their own dependencies
Deployments (and sub-deployments in an EAR) are isolated

Unzip to location with no spaces in folder

name (see notes)
e.g., Windows: C:\ and *nix: /usr/local
Creates the server root folder

1
e.g. jboss-as-7.1.1.Final or jboss-eap-6.0 *
<jboss> means this install location in the course
Server install includes these subfolders:
appclient: For client container files (7.1+)
bin: Startup scripts / config files
bundles: OSGI bundles
docs/schema: XML schema definitions
domain: Config files / folders for domains
modules: Server modules
standalone: Config files / folders for single
standalone server
welcome-content: Default Welcome Content

Modes in which Jboss can run ??

Standalone Server: A single server instance in a single JVM

Similar to previous version of JBoss AS
Management capabilities are in same process as the server
Useful for development and small production installations
Same structure and management tools as a server in a domain
Managed Domain: A multi-server, multi-JVM topology that can be run and managed from a single
control point
Has a more complex topology, with multiple processes used for management capabilities
Can have multiple servers on multiple hosts, all managed from a single control point

standalone server : Used where centralized management isn't needed

A single server doesnt gain from a domain
Development easier in standalone mode
Any individual server configuration in a domain can be achieved with a standalone server
Some complex scenarios (e.g. testing in clustered environments) may benefit from using a domain
If an organization already has multi-server management/maintenance capabilities, an
environment composed of multiple servers run in standalone mode may be a good option
Each mode includes a number of server configurations
WIth specifics of the server in XML configuration files
e.g. the services, ports, etc
Not recommended to modify the XML files directly
We'll see the other choices for management shortly
However, modifying them can be convenient
Standalone mode defines the following configurations (located
under <jboss>/standalone/configuration) (7.1)
standalone.xml: JEE6 Web Profile certified (the default config)
JEE6 Web profile, plus JAX-WS, JAX-RS, OSGi, and more
standalone-full.xml: Full JEE6 full profile
standalone-ha.xml: standalone plus clustering
standalone-full-ha.xml: JEE 6 full profile plus clustering
See notes for AS 7.0 profiles

To start JBoss AS, just run the <jboss>/bin/standalone script

After setting any necessary environment variables
standalone.sh for *nix variants *, standalone.bat for Windows
Unix: ./standalone.sh
Windows: standalone
By default, the script starts the standalone.xml configuration
Can use -c= to run a different configuration
./standalone.sh -c=standalone-full.xml

2
The <jboss>/bin Folder and Files
bin folder: scripts to start, stop and work with JBoss AS
Scripts include (in Windows - .bat, and Unix - .sh versions)
add-user: Add a user to security domain
domain: Starts a domain
domain.conf.bat (Win) / domain.conf (Unix): Configuration
properties used by the domain script
jboss-cli: The Command line interface (CLI) program
Named jboss-admin in AS 7.0
standalone: Starts a standalone server
standalone.conf.bat (Win) / standalone.conf (Unix):
Configuration properties used by the standalone script
wsconsume, wsprovide - Scripts for working with Web services

standalone script: Starts AS 7 in standalone mode

Options include those below
Option Description
--admin-only (7.1) Start management interfaces only
-b=<value>
-b <value>
Set system property jboss.bind.address to the given value
By default JBoss binds to localhost only (127.0.0.1). -b is
used to (covered more later)
-b<interface>=<value> Set system property jboss.bind.address.<interface> to the
given value
-D<name>[=<value>] Set a system property (These properties can then be used
in JBoss XML configuration files)
-h, --help Show help message
-P=<url> or-P <url> or
--properties=<url>
Load system properties from the given url
-c=<config>, -c <config>,
--server-config=<config>
Name of server configuration file (default standalone.xml).
Same as setting jboss.server.name property
-V or v or version Print version and exit

How can you Bind jvm to a specific IP address

Can bind AS 7 to a particular IP address
By default, binds to localhost (127.0.0.1)
To change this to allow remote access, or to specify a particular
IP on a multi-homed machine use :
./standalone.sh -b <IP Address> (*nix)
standalone -b <IP Address> (Windows)
-b 0.0.0.0 is a special wildcard indicating bind to all IP
addresses
-b actually sets a number of system properties (see notes)

Set in the following scripts that configure AS 7 Java process

Windows: bin\standalone.conf.bat

3
 *nix: bin/standalone.conf
Values - AS 7.1.1: -Xms64m -Xmx512m
Values - EAP 6: -Xms1303m -Xmx1303m
To change these, modify JAVA_OPTS appropriately, e.g.
*nix: JAVA_OPTS="-Xms256m -Xmx256m "
Windows: set "JAVA_OPTS=-Xms256m -Xmx256m "
You can also set your own JAVA_OPTS environment variable, but
this will override ALL settings in the config files

CLI accessed via the jboss-cli (7.1) script in <jboss>/bin

Use the jboss-admin script in AS 7.0
Below we show how to use it to shutdown the server (assuming it
is running on the same host where you issue the command)
./jboss-cli.sh --connect command=:shutdown (*nix)
jboss-cli --connect command=:shutdown (Windows)

Note:

When you run jboss-cli with no arguments, it brings up the

admin prompt for interactive commands, as shown at bottom
Type connect at the prompt (connects to local host)
[disconnected /] connect
The admin program comes up unconnected by default
Can also give a host:port argument to connect to the server there
(if the server at that location is configured to allow connections)
Type :shutdown at the prompt (shuts down the server)
[standalone@localhost:9999 /] :shutdown

jboss-modules.jar , the server boot jar, is under the root folder

Folder Description
appclient Folder for client container files (7.1+)
bin Startup scripts, admin srcipt, config files
bin/scripts CLI scripts to secure the management interfaces
bundles OSGI bundles (AS 7 is now compliant with OSGI)
docs/schema XML Schema defs (mainly for AS 7 configuration
files)
domain Root folder for running AS 7 in domain mode
modules Contains server modules (jar files)
standalone Root folder for running AS 7 in standalone mode
welcomecontent
Default home page for AS 7

The <jboss>/modules folder (shown below) contains the

modules (jars) shared by all server configurations
These contain the majority of the server code
Any configuration can access these modules
With the proper configuration - covered later

What are the AS 7 Server Configurations options ?

Ships with two configuration sets in two folders
domain: To run instances in domain mode
standalone: To run an instance in standalone mode
Configuration data is in [standalone | domain]/configuration

4
 Consist of XML files and associated folders
To create a new configuration, create a new XML file
Flexible - server core is very small
Each configuration can have different services deployed
Easy to copy / modify existing configuration file to your needs
It's a good idea to save the original JBoss configurations

Standalone Folder Structure

Folder for standalone server configurations
Note: Some folders are created when the server first starts
Folder Description
configuration Contains server config files e.g. standalone.xml,
and standalone-full.xml. Static configuration
information read only once upon startup
data Contains persistent data that survives server
restarts, Available for services that want to store
information on the file system.
data/content Contains user apps deployed via the
management
tools
deployments Default folder for auto-deploy of user apps (e.g.
Java EE apps)
lib/ext Contains jars referenced via the standard jar
extension-list mechanism
log Default location where server logging output is
placed
tmp Default location for temporary files used by server

Folder Structure & System Properties

System properties used for server configuration
Accessed in config files via ${propName}
Can include default value used if property is undefined
Below, 127.0.0.1 will be used as the default
${jboss.bind.address:127.0.0.1}
Some system properties affect the folder structure *, eg:
java.home: Java installation folder
jboss.home.dir: Base dir of the JBoss
distribution
jboss.server.base.dir: Folder where server
configurations exist
(default is ${jboss.home.dir}/standalone for a standalone server)
jboss.server.data.dir: Folder for persistent data file storage
jboss.server.deploy.dir: Auto-deploy folder for user apps
(default
${jboss.server.base.dir}/data/content)
jboss.server.log.dir: Folder for log files
jboss.server.tmp.dir: Folder for temp files

Use D define system properties

Below, we define a base dir to use server configurations under a folder
called testConfig (*nix version)
./standalone.sh -Djboss.server.base.dir=
$HOME/jboss-as-7.1.1.Final/testConfig

Ex: To define a property (e.g. testDB.userName), usable in config files

5
as ${testDB.userName}:
./standalone.sh -DtestDB.userName=EFCodd

What are the core configuration files in standalone mode?

Contains core configuration files, including:

Core server config files
standalone.xml and variants - e.g. standalone-ha.xml
The central repository for configuration info
Management tools make changes to the XML
logging.properties: Log manger properties file
Contains default logging configuration
Can customize logging in the server config file (standalone.xml)
mgmt-users.properties: Simple file-based security realm
Quick and easy configuration for management interface security
(secured by default in 7.1+)
Configured in server config file

What are Classes, Classloaders, and Classloading

A Java class is the object representing a type
The .class file on the file system
Must be loaded into the Java Virtual Machine (JVM) to be used
Java ClassLoaders dynamically load classes into the JVM
They locate libraries (jars), read them, and load their classes
Why do we care about this?
Classes must be available to programs that need them
Otherwise your program will fail
Classes often need to be isolated from each other
e.g. two versions of a library used in different apps
These requirements are often in opposition, and can cause
Problems

Classloading in Java EE Servers

Usually ignore this low level detail
App servers use classloaders in complex ways, that can be
confusing and create bugs / issues
Java EE app server requirements
Hot deploy / undeploy / redeploy - Problematic - can't unload a
class definition once it's loaded into the JVM
Class Namespace Isolation - Applications (e.g. an EAR) should
be isolated from each other - so they can use whatever libraries
and versions of libraries that they want
Traditional solution - give each deployment its own
Classloader

Classloaders form a hierarchy - each instance has a parent

Classloaders check their parent before loading a needed class
Three standard classloaders: Bootstrap (core libraries),
Extensions (standard extensions), and System (classpath)
The first two are fixed, the third can be user defined
In Java EE, apps got their

6
own classloader
Can access parent's classes,
but not sibling's classes
So classes in myear_1 and
myear_2 are isolated from
each other
Classes in the parents can
be accessed by both apps

Problems with Hierarchical Classloading

Especially apparent in JEE app servers
Cumbersome to share classes
Generally solved by putting shared classes on a common parent
of all interested classloaders
Leads to large monolithic classloaders containing everything
Cumbersome to isolate classes
For instance, to use two versions of the same library
Usually had to include it with the app
Could not load jars on demand
Usually loaded early in the boot-up process to be shared
Dependencies and references to jars were not clear
And could be difficult to change

Modular Classloading (JBoss Modules)

AS 7 uses a modular classloading mechanism
Based on the JBoss Modules project
A module is a named set of classes (Generally in a single jar)
Configured with the following (usually in a module.xml file)
The module's name
Its own resources (generally a jar file)
Its dependencies (other modules it sees)
Resources it exports (Only exported resources are visible to
modules that depend on it)
For example, the JBoss modular service controller module
Is named org.jboss.msc
Consists of a single jar file (e.g. jboss-msc-1.0.2.GA.jar)
Depends on a number of other modules

Advantages of Modular Classloading

Modules isolated from one another
Easy to use different versions of an API - just put them in
different modules (or slots) and import the one you need
A module imports exactly those modules it needs
It does not "see" classes or resources it doesn't use
No more "big ball of mud", helps eliminate "Jar Hell"
Dependencies are very clearly declared
Modules can be loaded on demand
Reducing start-up time, and application memory footprint
JBoss Modules is very efficient and fast loading

Application Dependencies
Applications usually have dependencies
e.g., a Web app (store.war) depending on an EJB (jtunes.jar)
Modules can be used for app dependencies as follows

7
 Deploy the EJB jar as a module
Assume module name com.javatunes.services
Add a dependency in the Web app manifest file (see below)
Usually the easiest way to share jtunes.jar among multiple apps
Can also package the WAR and EJB jar in an EAR
If jtunes.jar in the EAR's lib folder, automatically found
If elsewhere, add it to the WAR manifest (see notes)
Useful if only the Web app is using the jar

Modular Service Container (MSC)

MSC: Responsible for starting and managing AS 7 services
Complex problem - lifecycle management and dependencies
Extremely fast and efficient
Starts services in parallel - utilizing multi-core processors
Modular and parallel classloading (JBoss Modules based)
Very efficient deployment processing
Very efficient XML processing
Result in AS 7: Fast startup, reduced overhead
Only needed services are started (in parallel where possible)
Classloading very fast, only as needed
CPU / memory usage optimized

Server Building Blocks

Major building blocks of the server, include the following:
We look at a high level now
standalone.xml - The central server configuration file
Server extensions extend the server core
Based on JBoss Modules as described earlier
Subsystems configure available services in AS 7
A subsystem is a set of capabilities added to the server
For example, the Web container is added as a subsystem
XML configuration files configure the subsystems in a server
A profile is a named set of subsystems
Along with the details of each subsystem's configuration
Profiles are configured in the main server configuration file

standalone.xml High Level Overview

standalone.xml: Default configuration file for standalone mode
XML file is central repository for configuration info
This is a JEE 6 Web profile configuration (see notes)
Default location: <jboss>/standalone/configuration
A server configuration can include the parts shown below
High level - more detail later
Changes made directly to XML require a server restart to take affect

Server extension: Module extending the AS 7 core

It's a regular module in the modules folder
Written to an internal AS7 Extensions API

8
 It will register itself with the server runtime via this API
Most server capabilities added via extensions
They determine the capabilities available in a configuration
Below, is an sample of extension configurations
They are specified by their module name

Subsystems
Subsystem: Provides for configuration of an extension *
Also done in standalone.xml
Via <subsystem> elements within <profile>
Configures the exact capabilities added to the core server
Below - part of logging subsystem configuration
Declares handlers and logging categories
Requires org.jboss.as.logging extension

Profiles
Profile: A set of subsystems
Configured in a <profile> element as seen earlier
Along subsystem configurations in <subsystem>
A standalone configuration contains a single profile
It makes up the majority of a configuration
A domain can contain multiple profiles (covered later)

Subsystem list in standlone.xml

Server Infrastructure
Logging, Configuration and Admin, Security, Threads
Server Capability
Transactions, Deployment Scanner, Infinispan (caching)
JMX (Standard Java Management)
POJO, SAR (Service capabilities)
Java EE Technology Based
Java EE, EJB3, JAX-RS, JPA, Naming (JNDI), Web, Web
Services, JCA, Datasources
Mail, Activation
Weld (Dependency Injection)
OSGI

Paths

9
 A path (in a server config file) is a logical name for an actual
filesystem path
Can be declared once, then referenced by its logical name
Some paths are automatically provided by the server
e.g. jboss.server.log.dir specifies the folder for log output
Paths are easy to use
At bottom: The logging subsystem uses the
jboss.server.log.dir path to configure the log file location

Paths can be defined in the config file as shown at bottom

name: The name of the path
path: The actual filesystem path
relative-to: Name of another path this path is relative to

Interfaces and Socket Binding Groups

An interface declares a network connection endpoint
At bottom we show an interface named "management"
configured to use a single IP address
A socket binding group declares individual sockets available
on an interface
A named collection of sockets specifying the ports in a server
Configuration

Connecting to a Server Instance

Connect to a managed AS 7 instance to work with it
[disconnected /] connect
Connects to default host:port of localhost:9999
Or give a host:port argument, e.g.
[disconnected /] connect 192.168.1.5:9999
Can provide a --connect parameter to the script
And --controller to specify alternate host / port
./jboss-cli.sh --connect --controller=192.168.1.5:9999
To connect to a host other than localhost, the server must
allow remote connections (see notes)
You will also be prompted for user/password (see notes)
./standalone.sh -Djboss.bind.address.management=0.0.0.0

Basic CLI Commands

These are always available:
cn (or cd): Change the current node path to the argument;
connect: Connect to the specified host and port;
deploy: Deploy an application;
help (or h): Print this message;
history: Print or disable/enable/clear the history expansion.
ls: List the contents of the node path;
pwn (or pwd): Prints the current working node;
quit (or q): Quit the command line interface;
undeploy: Undeploy an application;
version: Prints the version and environment information.
There are other subsystem-specific commands
Such as adding a messaging queue
We'll cover these when we cover the subsystem

Management Tree Structure

Each node in the tree represents a resource, and may have
Attributes: Simple state information (a name/value pair)
Children: Child nodes
Operations: Actions to query or modify the resource state

10
 The root node has the following child types
extension: A list of extension modules
path: A list of named filesystem paths
system-property: A list of system properties to set on the server
core-service: Core services provided by the server
interface: List of named network interfaces on the server
socket-binding-group: List of socket bindings on the server
subsystem: List of subsystems on the server
deployment: List of deployments on the server

Web Console Overview

All new, very functional, management tool for AS 7
Simple, fast interface for server monitoring and configuration
Goal: Convenient alternative to XML files and CLI
Not a full fledged management tool like RHQ (Jopr) / JON
Capabilities include
Standalone server and domain management
Managing deployments
Configure socket bindings, network interfaces, JVM parameters,
and system properties
Management of 80% of subsystems *
We'll cover details when we cover a particular subsystem

11
 Web console enables monitoring of system
health, including:
JVM status (heaps, threads)
Transaction manager (commits, rollbacks,
)
Datasource usage (pool sizes, etc)
Web statistics (e.g. request/error statistics)
JMS metrics (topic/queue sizes, etc)
Persistence Units (cache usage, queries,
etc)
Accessible at
http://localhost:9990/console

Enabling Access to Web Console

In AS 7.1, the Web console is secured by
default
More details later - we'll cover enough here
to enable access
Add a user to the default security realm to
use the console
Via <jboss>/bin/add-users script
This script displays a series of prompts to add a user
User is added to <configuration>/mgmt-users.properties file
Browse to http://localhost:9990/console
Log in using the credentials you configured with add-user
The web console uses the http interface (covered more later)
To disable, leave out the interface, or disable the console:
<http-interface interface="management" port="9990" securityrealm="
ManagementRealm" console-enabled="false"/>

Profile and Runtime Information

Console divided into two main areas of information
Profile: Configuration information - reflecting config files
Runtime: Runtime information reflecting the running server
Accessible via tab at the upper right (see below)
Each area is further divided into sections by the left navigation menu
See Profile menu bottom left, and Runtime menu bottom right

12
Profile Information in the Console
The main Profile section divided into two
main sections
Profile and General Configuration in the
menu on the left of the console
Profile Section includes:
Core: Logging, Deployment Scanners,
Threads, JMX, Config Admin Service
Connector: JCA, Datasources, Resource
Apapters
Container: Naming, EJB3, EE,
Transactions, JPA
Security: Security Subsystem, Security
Domains
Web: Servlet/HTTP,

Summary of Management Techniques

We've seen three standard ways to manage servers
Which you use will depend on your needs
Modify the config file directly (e.g. standalone.xml)
Pro: Straightforward, easy to do with simple editor
Con: Requires server reboot, changes may be overwritten by management tools, requires
knowledge of the XML structure
Use the CLI
Pro: Can make changes without reboot, easy to script
Con: Fairly low level - cumbersome, requires detailed knowledge
of management resource structure
Use the admin console
Pro: Make changes without reboot, easy to use GUI, does not
require knowledge of the XML or management resource
structure
Con: No scripting, incomplete, slow for large number of changes

RHQ / JBoss Operations Network (JON)

RHQ is an open source integrated management platform
for managing diverse resources

13
 It is the open source version of JON (see notes)
Capabilities of RHQ include the following modules:
Inventory: Catalog IT assets across multiple platforms (Linux,Solaris, ),
servers (Apache, Tomcat,JBoss) and applications (Web apps, EJB, JMS, datasources, etc)
Monitoring: Collect and persist information, graph/chart data with trend analysis, define alerts,
initiate control actions on alerts, provide a complete audit trail, manage historical data
Administration: Provide single point for controlling diverse resources, including managing JBoss
applications (e.g. Web apps), providing access to and versioning of configuration files, scheduling
operations, and rolling back to previous versions
Content: Manages updates/patches to resources

RHQ Structure
RHQ consists of a few key components:
We will only give a very high level overview in this section
RHQ Server: The central server for managing resources
An application built on top of the JBoss application server
Provides a GUI console for managing resources
Agents: Distributed processes that communicate resource
information back to the RHQ server
Agents collect information on resources and send it to the server
Managed Resources: Resources managed by RHQ, including:
Platforms such as Windows, Linux, Java Platform
Servers that are present on a particular platform, such as JBoss
AS, Tomcat, Apache, IIS, etc.
Services for a server, e.g. Web app, or a JVM the server runs on

14
JBoss Logging Overview
AS 7 uses the JBoss Logging framework
Open source framework with fine-grained control of logging
Configuration / usage very similar to log4j
Currently not well documented
The log folder contains two logging files for AS 7
boot.log: Contains logging info from the core startup
server.log: Standard server logging file (multiple log files)
Server logging is configured in the logging subsystem
e.g. in standalone.xml
This configures logging output and destinations
The standard configuration logs to the console and server.log
Boot logging is configured by configuration/logging.properties

The log Folder and Logging Configuration

Three components work together to allow logging according to
message type/level, and to control formatting/ destination
Logger (Category): Named, configurable logger source
It can declare handlers and a level
Handler: Represents an output destination
Can include a level and a formatter
Formatter: Specifies the format of the logging output
Below, we show the XML configuration of a logger
It is named by its category attribute
It only logs messages at level WARN or higher
More on all of this soon
<logger category="com.arjuna">
<level name="WARN"/>
</logger>

JBoss supports levels from multiple logging frameworks

A JDK Logging level:
SEVERE | WARNING | INFO | CONFIG | FINE | FINER | FINEST
A JBoss Logging 3 style level:

15
FATAL | ERROR | WARN | INFO | DEBUG | TRACE
A special level:
OFF | ALL
Handlers
Handlers are the destinations of logging messages
Configured using different handler elements in the XML config
Can be configured with a level (filters) and a formatter (formats messages)
Different handlers available that log to different destinationsv
<console-handler>: Logs to the console
<file-handler>: Writes to a file
<periodic-rotating-file-handler>: Writes to file, rotates the file periodically
<size-rotating-file-handler>: Writes to file, rotates the file when it's a given size
<custom-handler>: Custom handler using JBoss API

Loggers, Handlers, and Levels

Loggers specify handlers, and can specify levels
At bottom, we show the root logger declaration (standalone.xml)
It specifies a level of INFO, and CONSOLE and FILE handlers
All loggers will inherit these values from the root logger
They can add additional handlers
They can specify a different level
Log messages must be at least the level of both the logger
and handler to be logged to that handler
For the console and root logger, they're configured as INFO

AS 7 Boot Logging
Logging during the kernel bootstrap (boot.log) is configured by the logging.properties file in the
configuration folder
Once the kernel is booted and the logging subsystem started,then the standard logging
configuration is used
You can change the boot logging behavior by modifying this file

Interface Specification
An interface configures a logical network connection
Declares a logical name, and criteria for selecting a physical interface
Centralizes network connection info in one place
Provides flexibility for configuration (especially for domains)
Usable by subsystems to specify their connection
Appears in server config file (e.g. standlone.xml)
Specify the physical interface in many ways, including
A specific IPv4/IPv6 address in standard dot notation
Any address
A particular network interface (e.g. a NIC)
Based on criteria, such as if the interface is up, whether it is a
loopback address, matching a range, etc.

inet-address: IPv6 or IPv4 address or a hostname

loopback: Indicates interface is a loopback
multicast: Indicates interface supports multicast
point-to-point: Indicates interface is point-to-point
up: Indicates interface is currently up
nic: The name of a network interface (e.g. eth0, eth1, lo).
nic-match: Regular expression to match nic names against
subnet-match: IP address plus number of bits in the address' network
prefix, in "slash notation"; e.g. "192.168.0.0/16".
not: Indicates the criterion should NOT be matched
any: Indicates match on any of the criterion

16
Socket Bindings and Socket Binding Groups
A socket binding is a named socket and an associated port
Centralizes configuration of ports
Subsystems use the socket binding by name to bind to a port
Each socket binding can specify its name, interface, port, multicast address / port, and fixed port
Only name and port are required
A socket binding group is a named collection of socket bindings
Allows easy configuration, use, and reuse of the group of sockets
Each socket binding group can specify its name, default interface, and port offset
The port offset can be used to increment all the ports in the group by a given increment

Controlling the Bind Address

You can control the bind address with system properties
Note how they are used in the interface configuration
value="${jboss.bind.address:127.0.0.1}"/>
Set this property with the -b option
Similiarly, use -bmanagement option to set the management
binding address
At bottom, we bind both the public and management
interfaces to a specific IP address
Web apps would now be accessible at this IP, e.g.:
http://192.168.1.129:8080

Port Offsets
To change the port assignments as a block, set the port offset
Can be done in the server config file, as shown at bottom
Can be done using system properties, e.g.
./standalone.sh -Djboss.socket.binding.port-offset=100
The port offset value is added to each socket binding
Removing conflicts with the default values
Useful for running multiple server instances on one host
Where you'll likely use a different server config folder
So there are different log, data, etc. folders

Java EE and JBoss Archives

Java EE defines a number of archive types for different purposes
Based on zip format to provide a convenient deploy package
JAR (*.jar): Java archive - most basic archive can contain simple libraries (e.g. a utility library) or
EJBs (Enterprise JavaBeans)
WAR (*.war): Web archive - contains web apps (servlets, JSPs, etc)
EAR (*.ear): Enterprise Archive - contains other Java EE modules - such as WAR files, jar files, etc.
JBoss AS also defines its own deployment archives and files
SAR (*.sar): Service Archive - Legacy from JBoss 5
*-ds.xml: DataSource configuration files
Not present in 7.0, reintroduced in AS 7.1

Deploying with the Web Console

Provides an easy to use interface
Access in main Runtime section - Deployments | Manage
Deployments (In EAP: Server | Manage Deployments)
Brings up the page shown below with the following capabilities
Add Content: Add a new application
Adds a new application but does not enable it
Enable/Disable: Enable / Disable a deployed app
Update Content (EAP): Update a deployed app
Remove: Remove a deployed app

17
Deploying and Enabling an App
Below, we show the console after deploying an app
Note it is disabled
At bottom, we show the same app after enabling it

Failed Deployments
If enabling an application fails due to errors, you can view the
error in the Web console messages
Accessible in the upper right of the console window

Deployment Scanner Overview

Allows deployment by placing files in a folder
standalone/deployments in the standard configuration
They will be deployed by the deployment scanner subsystem
The deployment scanner has two modes
Auto-Deploy: Directly monitors the content of the deploy folders

18
 Deploying new content, and redeploying modified content
Similar to previous JBoss AS versions
Additional capability (and complexity) using marker files
The default for archive files (war file, ear file, etc)
Manual Deploy: Deployment does not depend on app files
Marker files are used to control deploy/undeploy/redeploy of apps
Action is only taken when a marker file changes
The default for exploded content (content in an actual folder, not in
an archive)

Deployment Options
Archive Deployment: Adding an archive into a deploy folder
will deploy it
Exploded deployments let you add an actual folder into the
deploy folder (rather than an archive of the files)
Folder should have the same name/structure as the archive
e.g., you can have a Modules-With-Dependency.war folder with
the structure shown at bottom
Convenient for modifying an app in place
XML File deployment is supported for some deployments
Mostly for backward compatibility
For example, *-ds.xml files for datasource deployment

Marker Files (1 of 2)
The marker files consist of the name of the content (e.g.
MyApp.war) with one of the added suffixes below
.dodeploy: Placed by user to trigger deploy/redploy
For example, a file named MyApp.war.dodeploy
.skipdeploy: Disables auto-deploy content as long as present
.isdeploying: Placed by scanner to indicate it's in process of
deploying. Deleted when the deployment completes
.deployed: Placed by scanner to indicate that the content was
deployed. If deleted by user, the content will be undeployed
.failed: Placed by scanner to indicate that the content failed to
deploy into the runtime. File contents include reason for failure

.isundeploying: Placed by scanner when it notices a .deployed

file has been deleted and it is undeploying the content. Deleted
when the undeployment process completes.
.undeployed: Placed by scanner to indicate that the content has
been undeployed.
.pending: Placed by scanner to indicate that it has noticed the
need to deploy content but has not yet instructed the server to
deploy it.
Created if scanner detects auto-deploy content is currently copying,
or if there is a problem preventing auto-deployment
Marker files have uses in both auto-deploy and manual modes
Results of using marker files vary depending on circumstances

Deployment Examples (Manual Mode *nix)

Copy then Deploy an exploded deployment
<jboss-deploy> is <jboss>/standalone/deployments
cp -r example.war/ <jboss-deploy>

19
touch <jboss-deploy>/example.war.dodeploy
Undeploy currently deployed content
rm <jboss-deploy>/example.war.deployed
Replace currently deployed archive and deploy
cp example.war/ <jboss-deploy>
touch <jboss-deploy>/example.war.dodeploy
Replace currently deployed folder and deploy
rm <jboss-deploy>/example.war.deployed
wait for <jboss-deploy>/example.war.undeployed to appear
cp -r example.war/ <jboss-deploy>
touch <jboss-deploy>/example.war.dodeploy

Marker Files and Auto-Deploy

The marker files can be used with auto-deploy mode
Which the server still generates/updates
We show some examples below (*nix version only)
Undeploy currently deployed content (same as manual)
rm <jboss-deploy>/example.war.deployed
Replace unzipped content without deploying
Creating the .skipdeploy file prevents deployment
touch <jboss-deploy>/example.war.skipdeploy
cp -r example.war/ <jboss-deploy>
Deploy the content from above example
Deleting the .skipdeploy file triggers deployment
rm <jboss-deploy>/example.war.skipdeploy

Thread Pool Concepts

core-threads: Guaranteed capacity of pool
For all pool types, if a thread is requested from a pool, and less than core-threads currently in pool,
another thread is created
max-threads: The maximum size of the pool, If present
queue-length: Max size of queue for pools that have one
Threading subsystem defines different pool types that exhibit
different behavior based on the above
core-threads: Guaranteed capacity of pool
For all pool types, if a thread is requested from a pool, and less than core-threads currently in pool,
another thread is created
max-threads: The maximum size of the pool
If present, specifies a max number of threads in pool
queue-length: Max size of queue for pools that have one
Threading subsystem defines different pool types that exhibit
different behavior based on the above

Some Thread Pool Types

unbounded-queue-thread-pool: max-threads
When max-threads threads in use, new requests are always queued
No limit on size of queue - can grow indefinitely
bounded-queue-thread-pool: core/max-threads, queue-length
If core-size threads in use, enqueue requests until queue full
If queue full, create new threads until max-size reached
If queue full, then hand off task to executor (if specified) else discard
blocking-bounded-queue-thread-pool:
Same as bounded-queue-thread-pool, except task blocks if queue full
and max-size has been reached
queueless-thread-pool: max-threads
When max-threads threads in use, new tasks handed off to executor (if
specified) else discarded (there is a blocking version of this also)
scheduled-thread-pool: max-threads

20
 For tasks to be run periodically, or with delays

JBossWeb, the embedded Web container, is Tomcat based

Forked from Tomcat at Tomcat 6.0 - developed separately now
Adds support for CGI and PHP, better SSL performance, and more
Integrated with AS 7 as the Web subsystem within the standard configuration files
Supports Servlet 3.0 /JSP 2.2 / JSF 2.1
JBossWeb capabilities are similar to Tomcat
However, configuration/deployment is done differently
Deployment via AS 7 deployment methods, not any of the standard
Tomcat mechanisms
Configuration via the web subsystem, not the Tomcat server.xml
Tomcat logging is part of general AS 7 logging

Connector Configuration
Configures incoming connections to Web container
Many configuration attributes, including:
name: Name of the connector
protocol: Protocol for this connector (e.g. HTTP/1.1 or AJP/1.3)
We'll review AJP connector in clustering session
socket-binding: Socket binding reference (for address/port)
executor: Custom thread pool reference for execution *
Standard connector attributes:

Apache Portable Runtime (APR)

JBoss Web can use the APR for increased performance and
scalability
APR - highly portable library at heart of Apache httpd 2.2
APR main components
APR shared libraries, JNI wrappers for APR (libtcnative),
OpenSSL libraries
JBossWeb Native project (based on Tomcat Native) has binary
bundles for common platforms
If APR installed: Connectors automatically use it for certain
operations that improve performance, including:
Use sendfile for handling large static files
Use a socket poller for keepalive, increasing scalability of the

21
Server

JNDI Name Tree

Objects are organized in the JNDI directory as a tree
A JNDI name tree has a structure similar to a file system in which
The root directory is like the initial context
folders are like contexts
Files are like objects bound to one or more contexts
So, in JNDI terms, the path name /jdbc/MyDS (short for
MyDatasource) translates to
/ is the initial context
jdbc is a context under the initial context
MyDS - object bound to the jdbc context

Java and Database Connectivity

JDBC: Standard Java API to access relational databases
JDBC drivers: connect to databases via JDBC
Drivers implement the JDBC API and connect to the DB
Packaged into JAR files, and must be on the classpath
Making a JDBC connection to a DB requires:
The driver class name, which specifies what driver to use
The database URL, which specifies how to connect to the DB
Datasources: Java EE factory for database connections
Configured in app server with connection info, registered in JNDI
Apps look up DataSource in JNDI, and get connections
The server manages the connections to the DB

Datasource Advantages
Reduced dependencies - client has no DB connection info
You can change the DB without modifying application code
Authentication: The server can authenticate to the database
Authentication not needed in client
Connection pooling: Reuse of DB connections
Improves efficiency - Establishing a connection is expensive
The server keeps a pool of open connections available
Clients get one when needed, returns to pool when done
Rather than creating/destroying connections
Transparent to the client - Clients just use datasources, and app
server uses pooling behind the scenes
Pool configuration usually part of datasource configuration
Virtually all application servers support connection pooling, and
typically provide for pooling in datasource configuration

EJB3 Overview
EJB: Framework for creating server-side components:
Transactional, Distributed, Portable, Reliable, Secure, Scalable
Session Beans provide a business service
Distributed, transactional
Stateless Session Beans (SLSB) save no client-specific state
Stateful Session Beans (SFSB) save client-specific state
Message Driven Beans (MDB) integrate EJB with
messaging (JMS) systems
An MDB is an asynchronous message consumer
It consumes messages from a queue or topic
Bean instance lifecycle managed by the EJB container, as are distributed access, transactions,
instance pooling, threading, etc.

22
What Is JMS - Java Message Service?
A Java API used for interacting with a message service
The software implementing this API is the message provider
JMS is a standard Java EE API
Two parallel APIs that support the two messaging models
Pub/Sub and P2P
Very similar, and all are in the javax.jms package
Some JMS objects are administered objects
ConnectionFactory: Used to connect to server
Topics / Queues (Destinations): A messaging "address"
Configured in JMS provider and bound into JNDI
Looked up by clients in JNDI
This is standard for JMS

HornetQ and AS 7
HornetQ is the standard AS 7
messaging implementation
Present in *-full configurations
Open Source, very high
performance, reliability, and
scalability
HornetQ provides a JCA
adapter for integration with
JEE app servers
Makes integration easy
Apps may consume
messages (e.g. via an MDB)
Apps may produce messages
(e.g. an EJB or servlet)
All interaction done via the
JCA adaptor

AS 7 HornetQ/Messaging Configuration
Configuration is in messaging subsystem under a
<hornetq-server> sub-element, including:
General HornetQ configuration: Journaling/Persistence
<connectors>: Outbound channels (Connections this server

23
makes)
<acceptors>: Inbound channels (That a client can connect to)
<security-settings>: Default security settings
<jms-destinations>: Topics and Queues
<jms-connection-factories>: Configures JNDI objects for JMS
Many of these elements based on standard HornetQ config
Socket bindings are used by many of the above
HornetQ has a lot of capability and configuration options

Dead Letter and Redelivery Configuration

Can be configured for different addresses (destinations)
Uses <address-setting> with optional wildcards
Excerpt below applies to all addresses (using # wildcard)
dead-letter-address: Destination for undelivered messages
e.g. Too many delivery failures for specified destination
expiry-address: Destination for expired messages
e.g. Message sits in queue and no consumer reads it
redelivery-delay: Interval between delivery attempts

General Security Requirements

Authentication: Reliably identifying a user
For example with a name and password
Authorization: Granting of access rights
Users have differing levels of access to resources
Data Integrity: Information must be protected from tampering
Generally done by encryption of some sort, e.g. SSL
Data Privacy: Information must be protected from
unauthorized access
Also generally done using encryption

JBoss AS Security Requirements

Many areas in JBoss where security is a concern, including:
Management interfaces and applications
e.g. Web Console and CLI
User Apps: Authenticating and authorizing users
Registries: Stored user information
user/password data in a data store
Resource access information (e.g. a DB password for a DataSource)
Physical Access Points: Wire level access to information
Web Tier: Various security points such as HTTPS and configuration
of the Web server
Connectors: Multiple access points to the JBoss server itself
(remoting connector, JMX access, etc.)
We'll review JBoss AS and Java EE security at a high level first

Security Realms for Management Interfaces

Security realms secure access to management interfaces
Also used to secure remoting connector (EJB remote access)
Configured in server config file as part of <management>
Not as a subsystem
SASL-based (Simple Authentication and Security Layer)
Security realms:
Access a data store for user authentication/authorization data
Can define a server identity
Two realms defined by default
ManagmentRealm: Controls access to management interfaces
The native and http interface and related apps (CLI, Web console)
ApplicationRealm: Controls access to remoting connector

24
 May also be used by other subsystems / user apps

Security Domains for App Security

Security domains used for application security
Contain user identities and credentials (e.g. name/password)
Map users to security roles for role-based security (see notes)
JAAS-based (Java Authentication and Authorization Service)
Security domains configured in security subsystem
Specify login module(s) for authentication and role mapping
Login modules can integrate with different security architectures
e.g. LDAP or a database
Applications or subsystems specify a security domain
Making the domain's user and role information available
Applications specify access based on these roles

<authentication> element specifies an authentication policy

Configured with access to the data store holding security policy, e.g.
File names/locations for a file-based module
Connection info for an LDAP server + object names that hold needed data
Currently the following authentication options are available
jaas: JBoss AS security domain holds security data
properties: Properties files hold security data
users: user/password in configuration XML (for simple testing only)
ldap: Uses LDAP server for authentication

Common Login Modules

AS 7 login modules (by Code name : Classname) include: *
UsersRoles : UsersRolesLoginModule: Simple file-based login
module supporting multiple users/roles - convenient for testing
RealmUsersRoles: Extends UsersRoles to support hashed data
used in security realms
Remoting: Extracts identity from remoting connection
DatabaseUsers : DatabaseServerLoginModule: JDBC based
Ldap : LdapLoginModule: LDAP server based login module
Identity : IdentityLoginModule: Simple login module that
associates hard-coded user name to any subject it authenticates
Certificate : BaseCertLoginModule: X509Certificates based
CertificatRoles : CertRolesLoginModule & DatabaseCertificate :
DatabaseCertLoginModule extend the behavior to obtain
authorization roles from a properties file or DB
Custom login module: Written to JBoss AS API

Login Module Processing

Authentication processing done via login modules in a domain
Modules used in the order listed in the configuration
The flag attribute controls how a module participates (see notes)
flag=required: the login module is required to succeed - authentication
proceeds down the stack on success or failure
flag=requisite: the login module is required to succeed - authentication
proceeds down the stack on success, returns immediately on failure
flag=sufficient: the login module NOT required to succeed -
authentication returns immediately on success
flag=optional: the login module NOT required to succeed - authentication
proceeds down the stack on success or failure

Ldap - LDAP Based

Ldab | LdapLoginModule: Login module authenticating against

25
LDAP server
Used if your user/role information is stored in an LDAP server
The LDAP server is accessed via a JNDI LDAP provider
There are a number of configuration options for connecting to the
LDAP server, including:
java.naming.factory.initial: InitialContext factory to use
java.naming.provider.url: URL for LDAP server
java.naming.security.protocol: Protocol for secure access (e.g.
SSL)
java.naming.security.authentication: Security level to use
java.naming.security.credentials: Login credential (e.g.
password)
Authentication of a user is done by connecting to the LDAP server
using the configuration options above

TLS/SSL & HTTPS - Transport Level Security

TLS (Transport Layer Security) and SSL (Secure Socket Layer) are
standards for authenticated and encrypted communication
Runs above TCP/IP and below higher-level protocols (e.g. HTTP)
Allows SSL-enabled server to authenticate itself to SSL-enabled client
Allows the client to authenticate itself to the server
Allows both machines to establish an encrypted connection
Encrypts all data sent between client and server
HTTPS is the Web standard that uses HTTP over TLS/SSL

TLS/SSL Meets Some Security Needs

TLS/SSL is transport level security, and provides for:
Data Privacy All data is encrypted after an initial handshake to
define a secret key
Data Integrity Message transport includes a message integrity
check
Authentication A peer's identity can be authenticated using
asymmetric or public key cryptography (during initial handshake)
TLS/SSL is based on public / private key encryption
To support a TSL/SSL connection, a server needs a certificate
A certificate generally includes the server name, a trusted
Certificate Authority (CA), and the server's public key
We'll focus on the configuration required
See the notes for some more detail on TLS/SSL
More discussion is beyond the scope of the course

TLS / SSL Requires Server Setup

The following are needed to support TLS/SSL on the server
public/private key pair for encryption
certificate - which is a digitally signed statement stating that a
public key has a certain value (may be signed by the public key
owner, or verified by a third party - a Certificate Authority or CA)
keystore - which is a database holding public/private key entries
and certificate entries
Key entries: Generally a private key accompanied by a certificate

26
chain for the corresponding public key
Trusted certificate entries: Contains a single public key certificate
belonging to another party
To support TLS/SSL/HTTPS on JBoss AS, you must set up a keystore with a public/private key pair

The keytool Program

The Java keytool program, bundled with the Java JDK,
helps in creating and managing a keystore
Can create/administer public/private key pairs and certificates
Can store certificates of their communicating peers
A keystore is used to store the keys and certificates
By default, this is a file named .keystore in your home directory
Private keys are protected by password
All entries are identified by an alias
It supports X.509 certificates (only)
keytool has a lot of capability and configurability
We will only go into the details that are relevant to us here

Using the keytool Program

Options and commands for the keytool program include:
-keystore keystore_location: The keystore file location
-storepass storepass: Password for the entire keystore
-genkey: Generate public/private key pair, & wrap in a X.509 self signed
cert stored as a single element cert chain. Options include:
-alias alias: Identity of the new key pair
-keyalg keyalg: Algorithm for generating key pair (DSA or RSA)
-keypass keypass: Password for the generated private key
-validity valDays: Number of days certificate is valid
Note - if the -genkey command is used, and the keystore file specified does
not exist, it will be created
-list [-alias alias]: List the contents of the given keystore entry,
or of the entire keystore if no alias provided
-export [-alias alias] [-file cert_file]: Export an entry,
store in a file

The -keystore and -storepass options can be used with most commands
Below are the defaults for various option values
-alias "mykey"
-keyalg "DSA"
-keysize 1024
-validity 90
-keystore the file named .keystore in the user's home directory
The RSA algorithm should be preferred as a secure algorithm, and this also ensures general
compatibility with other servers and components.

keytool -genkey -alias ssl -keyalg RSA

-keystore default.keystore -validity 3650

Cluster Partitioning, Multiple Servers / Host

Cluster membership based on multicast address

27
 Partition a cluster by configuring different address (shown
later)
Only nodes with same address will cluster together
Default multicast address is 230.0.0.4
Multiple instances per machine (Sample cluster config)
Specify multicast address to partition (and port offset as
required)

JGroups
JBoss AS clustering is layered on top of JGroups
JGroups: Toolkit for reliable multicast communication
Provides channels for tracking cluster members and reliable messaging between members - the
basis of JBoss AS clustering
Clustering configuration includes JGroups configuration
Complex you generally don't modify it
Multicast address for partitioning can be done with system properties when starting the server
Usually the multicast configuration of your network is at the root of clustering problems

Example: Starting Cluster Instances

Below, we show startup of two server instances that specify their clustering multicast address and a
port offset (for *nix)
This is for two servers instances on one host
Cluster multicast address: Partitions instances into a cluster
Only instances with this address will join this cluster
Port Offset: Lets the two instances to run on the same host
./standalone.sh -Djboss.socket.binding.port-offset=100 -Djboss.default.
multicast.address=230.0.0.41-c=standalone-ha.xml

./standalone.sh-Djboss.default.multicast.address=230.0.0.41-c=standalone-ha.xml

JGroups Troubleshooting
For clustering problems, first test your IP multicast behavior
Network configuration is main cause of clustering problems
JGroups provides simple testing programs (not in EAP-see notes)
McastReceiverTest and McastSenderTest
To run, open two terminal windows in the folder:
<jboss>/modules/org/jgroups/main
Execute the following (one in each window)
java -cp jgroups-nnn.jar org.jgroups.tests.McastReceiverTest -mcast_addr
224.10.10.10 -port 5555
java -cp jgroups-nnn.jar org.jgroups.tests.McastSenderTest -mcast_addr
224.10.10.10 -port 5555
Use the actual jar name e.g. jgroups-3.0.6.Final.jar

mod_cluster Overview
mod_cluster lets the cluster dynamically send current configuration to the load balancer
Load balancer forwards requests to the appropriate server based on the current configuration

mod_cluster Advantages
Dynamic Configuration: No explicit (static) configuration of worker nodes, proxies, or apps
required
Workers communicate their state, deploy/undeploy of apps, etc.
httpd proxies advertise their presence to workers (see notes)
Can also configure httpd proxies statically
Server-Side Load Balance Calculations: Worker nodes provide load balance info and factors
More robust and accurate view than static configuration

28
 Fine grained web-app lifecycle control: Worker nodes forward app lifecycle events to balancer
Allows much better handling of undeployments
AJP is optional: HTTP, HTTPS, or AJP are all supported
Can use any of these for httpd/node traffic - For SSL use see:
http://docs.jboss.org/mod_cluster/1.2.0/html/UsingSSL.html

Module configuration in Apache httpd

mod_cluster consists of the httpd modules below *
mod_slotmem: Shared slotmem memory provider
mod_manager: Reads info from JBoss & updates shared memory info
mod_proxy_cluster: Contains balancer for mod_proxy
mod_advertise: Advertises balancer IP address/port via multicast
Also requires standard mod_proxy / mod_proxy_ajp modules *

Configured in httpd.conf - the standard httpd config file

LoadModule slotmem_module modules/mod_slotmem.so
LoadModule manager_module modules/mod_manager.so
LoadModule proxy_cluster_module modules/mod_proxy_cluster.so
LoadModule advertise_module modules/mod_advertise.so

<IfModule manager_module>
Listen 127.0.0.1:6666
ManagerBalancerName mycluster
<VirtualHost 127.0.0.1:6666>
<Location />
Order deny,allow
Deny from all
Allow from 127.0.0
</Location>
KeepAliveTimeout 300
MaxKeepAliveRequests 0
AdvertiseFrequency 5
EnableMCPMReceive
<Location /mod_cluster_manager>
SetHandler mod_cluster-manager
Order deny,allow
Deny from all
Allow from 127.0.0
</Location>
</VirtualHost>
</IfModule>

Some mod_cluster Configuration Properties

mod_manager:
EnableMCPMReceive: Enable VirtualHost to receive MCPM
Maxsessionid: Max number of sessions to store
ManagerBalancerName: Balancer name if not provided by AS 7
AllowDisplay: Display additional info on manager web page
mod_advertise:
ServerAdvertise (On|Off): Advertise balancer to AS 7 (via multicast)
AdvertiseGroup IP:port: Multicast address to use (must match the AS 7 configuration)
AdvertiseFrequency (secs): Time between advertise messages
AdvertiseSecurityKey: Key to pass to AS 7 to identify balancer
mod_proxy_cluster:
ProxyPassMatch/ProxyPass: mod_proxy directives that can be used to configure httpd to serve
static pages (e.g. images) For example, to let httpd server gif files (see mod_proxy docs for more
info): ProxyPassMatch ^(/.*\.gif)$ !

29
Domain Mode Overview
A managed domain lets you run / manage multiple servers
Coordinates management of a set of servers
Provides single, centralized management point
Addresses complexities of multi-server installations
Individual configuration inefficient
Individual management complex and error-prone
Adds additional management layer to handle configuration and lifecycle of server instances
Builds on capabilities/configuration we've already seen
Individual server configuration similar to standalone mode
Can be used for clusters or non-clustered servers
Not dependent on clustering - useful for any group of servers

Domain Mode Concepts / Components

Domain: Logical grouping of servers with centralized configuration and control - can span multiple
host computers
Domain Member (or node): Server in a domain
Host Controller: Manages all members on a given host
An AS 7 instance
Has a host.xml file
Domain Controller: Single point of control for the domain
A specially configured Host Controller
Has a domain.xml file
Server Group: Set of server instances managed as one
Each server in the group has identical configuration
Every domain member is part of a Server Group

domain.xml - Central Domain Configuration

domain.xml - Core configuration for entire domain
One instance in a domain - with the domain controller
Defines the domain's capabilities
Available profiles, interfaces, socket bindings
domain.xml includes the elements shown below *
<profiles> holds a set of profile definitions
<interfaces> defines interface names, but not configuration
Interface configuration on a per host basis (in host.xml)
<server-groups> defines collections of servers

<profiles> contains a set of complete profiles

Each profile is named and contains its own subsystems
Domain members must use one of these profiles
The example below shows the structure of the profiles
<interfaces> contains a listing of <interface>
Each interface is named, but contains no binding
Bindings are contained in the host.xml file

<socket-binding-groups> contains set of <socketbinding-

group>
Each group defines a complete set of socket bindings
Used in a server-group, and support the profiles in the domain

<server-group> defines a complete server configuration

Associates together a profile, socket binding, jvm configuration,
deployments, and more
Used by host.xml to define server instances for that host
<jvm>: Defines a JVM and its environment
<socket-binding-group>: Configures the socket binding used

30
 <deployments>: Configures deployments to the server group

host.xml - Per Host Configuration

host.xml - Configures server nodes on host controller
One host.xml per host controller (often one per machine)
name="hostName" configures the name of the host contoller
Domain controller (master) is also configured via a host.xml file
host.xml includes the elements shown below *
<management>: Security realms, management interfaces
<domain-controller>: Domain controller connectivity info
<interfaces> interface definitions with bindings
<jvms>: JVM configuration for running servers
<servers>: Server configurations (group, jvm, socket binding )

Domain Controller (DC) Startup

Start domain via domain script in <jboss>/bin directory
Default uses domain.xml / host.xml files in domain/configuration
./domain.sh
Starts server based on host.xml file (we assume as DC here *)
DC is now available for host controllers to connect to
Host controllers will initiate connection
Host controllers get their server configurations from the DC
DC has full management interfaces
Including Web console and CLI, which can be used to manage
complete domain
You can monitor/manage the state of each server
Can deploy/undeploy to the domain controller
Making content available for the domain
Can deploy to server groups - deploys to the servers in the group

Tasks to Perform
To start using the domain-controller folder, you will use the
jboss.domain.base.dir system property as follows
Open a terminal/command window in <jboss>/bin
Use domain to start the DC (will use domain.xml and host.xml)
We show *nix (below) and Windows (at bottom) examples (AS 7.1)
Type these all on one line (they are broken up for space reasons)
The server should start up as the DC
Look at the console window for logging output - you'll see the
[HostController] logging output
Lab
domain -Djboss.domain.base.dir=C:\jboss-as-7.1.1.Final\domain-controller
./domain.sh
-Djboss.domain.base.dir=/usr/local/jboss-as-7.1.1.Final/domain-controller

Tuning Overview
JBoss can use significant resources in a number of areas
You should be aware of what resources are used, and their
optimizations to get the best response time / throughput
JBoss uses significant resources in the following areas:
CPU: A limited resource - once you reach 100% CPU utilization,
you can't do anything more
Memory: A limited resource. Though operating systems extend
physical memory with virtual memory, paging can cause
performance issues and should be minimized
Threads: A limited resource. Each thread uses memory for its
stack, and has overhead due to management by the OS
Network/Serialization: Network latency and overhead from

31
serialization can be significant
Locking: Shared resources may be locked, causing contention

Tuning a system depends on what it's doing

Tuning a single server with a few users for fast response is
different from tuning a cluster with 10000 users
A system that is doing mostly messaging is different from a
system that is doing web-application type processing

Memory, Memory, Memory

What are the three most important areas for tuning JBoss
Memory, Memory, Memory
Java EE app servers like JBoss use a lot of memory in production situations with real loads
It's likely that the single most productive thing you can do for improving server performance is to
make more memory available
Provide as much physical memory as you can
Memory continuously becomes cheaper, this is the easiest and most productive thing you can do
It may make sense to use a 64bit OS and JVM (fairly available these days) to allow for heap sizes
larger than 2-4 GB
Be aware that physical memory may not be used fully or most efficiently if you don't consider the
next two areas
Java Virtual Machine (JVM): What JVM configuration is available?
Operating System: What OS configuration is available?

JVM - Heap Size

JVM limits memory allocated for the heap
Additional physical memory, won't be used unless you modify the -Xmx values seen earlier
Modify -Xmx to take advantage of actual physical memory
Typically, to a max of about 75% of available physical memory
For production, generally use same value for -Xms and Xmx
Determine heap requirements first: Start with a small Xms, load
the server and observer maximum value
Use JAVA_OPTS values in standalone/domain.conf (.conf.bat
for windows) in <jboss>/bin
JAVA_OPTS="-Xms1536m -Xmx1536m (*nix version)

JVM - Perm Space

The JVM also has a permanent memory area, called perm space, that it uses to allocate things like
class definitions
This space is never reclaimed, and can grow as a running server loads and unloads deployments
since classes can't be unloaded
If you run out of perm space, you'll get an error message like: java.lang.OutOfMemoryError:
At bottom is an example of modifying the perm space using the appropriate JVM options ( via
JAVA_OPTS)
MaxPermSize is set to 256m in the default run scripts
Make sure you take this memory usage into account when figuring out what a good -Xmx setting is
set JAVA_OPTS=XX:
PermSize=64m XX:
MaxPermSize=256m
-Xms1536m Xmx1536m %JAVA_OPTS% (Windows version)

JVM - Garbage Collection

JVMs have to periodically "take out the garbage"
Objects with no references are reclaimed by the JVM
This memory reclamation is called garbage collection (GC)
GC efficiency is a critical part of the JVM
Modern JVMs are very efficient at GC
Also fairly flexible, with different configuration options

32
 You may need to tune GC if it becomes a bottleneck
Don't tune until you have some evidence that it's needed
Modern JVMs use generational garbage collection
Because objects have a high infant mortality - newly allocated objects much more likely to be
reclaimed than older ones
Newly allocated objects are stored in a separate space (called Eden) than older objects (called
Tenured)

JVM - Minor vs Full Collections

Generational GC has two types of garbage collections
Minor collection: Copy collection of objects from young generation typically fast as most objects
are dead
Major collection: In-Pace collection of objects from tenured generation typically much slower as
most objects are alive
You can see the GC characteristics of your server by using the -verbose:gc flag on the JVM
This can give you a good idea of what is going on with GC
Note how much longer the Full GC took

JVM - Optimizing Generational GC

You can tune the Eden|Tenured sizes to minimize full collections
This can improve total GC time (see note)
A bigger young generation gives fewer minor collections
A smaller tenured generation gives more full collections
You need to tune these appropriately for your server and application
NewRatio sets the young to tenured ration
-XX:NewRatio=3 gives a young : tenured ratio of 1:3
i.e. the size of (eden + survivor spaces) will be the total heap size
NewSize and MaxNewSize can be used to set absolute values for
young generation (from below and above)
Can use this for more fine grained tuning
Make sure that Eden is never larger than the committed heap
This will result in only major collections, and no minor

JVM - Parallel Garbage Collectors

Modern JVMs support parallel GC - for multi-processor machines
If you want to do that much tuning, make sure that the GC is
really a bottleneck by profiling (using -verbose:gc or other tools)
The Parallel Compacting Collector collects both Young and Old

33
generation objects in parallel - it maximizes
throughput
Used when -XX:+UseParallelOldGC is
passed on command line
Uses parallel version of "Stop-theworld"
young generation serial
collector (shown at right)
Uses compacting three-phase
parallel collection on old generation
Designed to improve on and replace previous
parallel collectors

Other GC choices
Concurrent low pause collector collects the tenured generation
concurrently with application execution
Minimize pauses rather than maximizing throughput - for apps more
sensitive to pauses than dependent on high throughput
Used when -XX:+UseConcMarkSweepGC passed on command line
The Garbage-First (G1) collector - targeted at multi-processor
machines with large memories - high throughput, low pause times

OS - Memory and Threading

Thread stack size can also be an issue -
App servers can easily use 1000+ threads
Linux/Intel: Default thread stack size = 512K (512 MB for 1000 threads)
Wintel is 256K
Adds up to a lot of memory - you may be able to reduce the stack size
Make sure you test to make sure this works *
On Windows use -Xss for the JVM, on *nix use the ulimit command

OS and Hardware - Other Considerations

Linux has a good threading implementation that scales well
Pre-2.6 releases had major threading issues, but are unlikely to be encountered these days
A multi-processing machine will help scalability
App server is heavily threaded, and parallel threads can run on multiple processors
One of the parallel / concurrent GC options will also allow you to distribute the GC load over
multiple processors
Make sure you set the appropriate flags to use the parallel GC
The JVM should automatically use the multiple processors for other threads
This won't help, if your system is mostly waiting for other resources (e.g. the database)

Datasource Tuning
Datasources in JBoss provide elements for tuning the connection pool, including:
min-pool-size: the minimum number of connections in the pool
max-pool-size: the strict maximum size of the pool
blocking-timeout-wait-millis: maximum time to block while waiting for connection before throwing
exception
idle-timout-minutes: the length of time an idle connection will remain in the pool before it is
removed
You can tune these as appropriate for your system (see notes)
You can also configure a transaction isolation for a datasource
All connections will have the configured isolation level
Don't use XA datasources unless you really need them
They are considerably slower than non-XA versions

Web Container Tuning - Connectors

Can set a custom executor (thread-pool) on a web connector
<connector name="http" executor="http-executor" />

34
Thread pool of same name (http-executor) is used (see bottom)
Most important values: core-threads and max-threads
Too low a value means requests will idle waiting for thread
Too high a value will use extra resources
Need to understand how the executor threads are being used
Can monitor threads with a tool like JConsole
Make sure they're not blocked waiting for another resource (DB)

Logging
Logging, especially to the console, can slow things down
Can remove the console logging in the <root-logger> element in the logging subsystem, as
shown below
Can also modify the logging levels that are used
AS 7 comes configured to log at INFO level
Can change this to a higher level (e.g. WARN) - see below
Remember, you can always switch to another level at runtime
Developers should use logging, not print to the console

35