Professional Open Source™

JBoss Production Deployment
Ready, set, go!

© JBoss, Inc. 2003-2005.

October 14, 2008

1

Professional Open Source™

Installing Jboss in Production

Database

© JBoss, Inc. 2003-2005.

October 14, 2008

2

Database

- JDBC
Professional Open Source™

– – –

Type 1: JDBC-ODBC (Windows), requires an ODBC driver on the client machine Type 2: JDBC calls => native API, requires a native driver on the client machine Type 3: JDBC calls => network protocol, requires a Type 1/2/4 driver to access the database • A type 3 Network Server allows to set up a connection pool

Type 4: Full Java driver

© JBoss, Inc. 2003-2005

3

Database

- Connection Pool and Datasource
Professional Open Source™

A connection pool is a group of ready to use connections to a database. It provides the following benefits: – Time and overhead are saved by using existing database connections – The number of connections to a database can be controlled A datasource provides a way for a JDBC client to obtain a database connection from a connection pool. A datasource is: – A reference to a connection pool stored in JNDI – Associated to each connection pool

© JBoss, Inc. 2003-2005

4

Database

- Datasource
Professional Open Source™

Jboss Datasources are described in *-ds.xml files, which have to be placed in a deploy/ directory to be hot-deployable.  What to do if you want to switch from the embedded HSQL database to a production database ?
– – Remove the hsqldb-ds.xml file from the deploy directory Drop your xxx-ds.xml to the deploy directory, using DefaultDS as jndi-name (or a dedicated name)

Datasources have different behaviors: transactional or non-transactional
– <local-tx-datasource> • Simulates the XA Protocol (Two-Phase Commit) • Should not be used in same TX with other data sources <xa-datasource> • Integrated with DB’s XA interfaces • Using XA-compliant JDBC drivers • Implies a Transaction Manager for handling the Two-Phase-Commit protocol <no-tx-datasource> • Transaction free data source • Application managed connections

© JBoss, Inc. 2003-2005

5

Database

– Configuring a local-tx-datasource [1]
Professional Open Source™

<local-tx-datasource> <jndi-name>DefaultDS</jndi-name> <connection-url>jdbc:oracle:thin:@host:1521:sid</connectionurl> <driver-class>oracle.jdbc.driver.OracleDriver</driver-class> <connection-property name=“optional-prop-name”>prop value</connection-property> <transactionisolation>TRANSACTION_READ_COMMITTED</transactionisolation> <min-pool-size>0</min-pool-size> <max-pool-size>20</max-pool-size> <blocking-timeout-millis>5000</blocking-timeout-millis> <idle-timeout-minutes>15</idle-timeout-minutes> <new-connection-sql>SELECT COUNT(*) FROM SOME_TABLE</new-connection-sql> <check-valid-connection-sql>SELECT COUNT(*) FROM TABLE</check-valid-connection-sql> <valid-connection-checker-class-name> org.jboss.resource.adapter.jdbc.vendor.OracleValidConnectionCh ecker </valid-connection-checker-class-name> <application-managed-security/> <security-domain>myDomain</security-domain> <user-name>scott</user-name>

© JBoss, Inc. 2003-2005

6

Database

– Configuring a local-tx-datasource [2]
Professional Open Source™

– JNDI name is referenced by java:/name – <driver-class>, <connection-url> and <connection-property> depend on the driver type according to the DB provider

<local-tx-datasource> <jndi-name>DefaultDS</jndi-name> <connectionurl>jdbc:oracle:thin:@host:1521:sid</connection-url> <driver-class>oracle.jdbc.driver.OracleDriver</driver-class> <connection-property name=“optional-prop-name”>prop value</connection-property>

© JBoss, Inc. 2003-2005

7

Database

– Configuring an xa-datasource [2]
Professional Open Source™

– Define URL to connect to database – Different tags for driver class and properties
<xa-datasource> <jndi-name>DefaultDS</jndi-name> <connection-url>jdbc:oracle:thin:@host:1521:sid</connection-url> <xa-datasource-class>oracle.jdbc.driver.OracleDriver</xadatasource-class> <xa-datasource-property name=“optional-prop-name”>prop value</xa-datasource-property>

© JBoss, Inc. 2003-2005

8

Database

– Transaction isolation
Professional Open Source™

– JDBC transaction isolation – Used only with local-tx-datasource and xa-datasource
<local-tx-datasource> <jndi-name>DefaultDS</jndi-name> … <transactionisolation>TRANSACTION_READ_COMMITTED</transactionisolation>

© JBoss, Inc. 2003-2005

9

Database

– Datasource Pooling [1]
Professional Open Source™

 Blocking timeout if max pool size has been reached
– Exception thrown on timeout

 Unused connections in pool closed after time limit
<local-tx-datasource> <jndi-name>DefaultDS</jndi-name> … <min-pool-size>0</min-pool-size> <max-pool-size>20</max-pool-size> <blocking-timeout-millis>5000</blocking-timeout-millis> <idle-timeout-minutes>15</idle-timeout-minutes>

© JBoss, Inc. 2003-2005

10

Database

– Datasource Pooling [2]
Professional Open Source™

 Invoke SQL on connection creation and/or pool access
– Tests connection validity. DB may timeout.

 You can write your own checker
– Oracle provides API to ping DB.
<local-tx-datasource> <jndi-name>DefaultDS</jndi-name> … <min-pool-size>0</min-pool-size> <max-pool-size>20</max-pool-size> <blocking-timeout-millis>5000</blocking-timeout-millis> <idle-timeout-minutes>15</idle-timeout-minutes> <new-connection-sql>SELECT COUNT(*) FROM SOME_TABLE</newconnection-sql> <check-valid-connection-sql>SELECT COUNT(*) FROM TABLE</check-valid-connection-sql> <valid-connection-checker-class-name> org.jboss.resource.adapter.jdbc.vendor.OracleValidConnectionCheck er </valid-connection-checker-class-name>

© JBoss, Inc. 2003-2005

11

Database

– Other tags for optimization
Professional Open Source™

 <track-statements>: JBoss will automatically close leaked statements when connections are returned to pool
– JBoss also automatically closes leaked connections allocated within EJB invocation

 <prepared-statement-cache-size>: caching can improve performance
– 10% on our Specj benchmarks

<local-tx-datasource> <jndi-name>DefaultDS</jndi-name> … <track-statements>true</track-statements> <prepared-statement-cache-size>100</preparedstatement-cache-size>

© JBoss, Inc. 2003-2005

12

Professional Open Source™

Installing JBoss in Production

Deployment Ordering

© JBoss, Inc. 2003-2005.

October 14, 2008

13

Deployment Ordering

– Deployment Ordering?
Professional Open Source™

Remember the microkernel boot sequence : is any deployment ordering necessary for:
– JARs in /lib ? • NO! These are just JARs/ZIPs that extend the JBoss classpath with new code. – MBean definitions in conf/jboss-service.xml ? • NO! JBoss will start these MBeans in the order in which they are defined in the file, i.e. sequentially. – Packages in DeploymentScanner urls ? • YES! – What if a CMP EJB starts before its DataSource is started? – What if a Topic is created before JBossMQ is started?  Dependencies are needed to correctly start applications/services deployed
<mbean code="org.jboss.deployment.scanner.URLDeploymentScanner ... <attribute name="ScanPeriod">5000</attribute> <attribute name="URLs">deploy/,deploy2/,http://myserver/</attribute> <attribute name="RecursiveSearch">True</attribute> <!--attribute name="ScanEnabled">false</attribute--> </mbean> in conf/jboss-

service.xml
© JBoss, Inc. 2003-2005

14

Deployment Ordering

– Dependencies: Implicit vs. Explicit
Professional Open Source™

Dependencies between MBeans can be either implicitly or explicitly stated:
– JBoss provides both implicit and explicit means to state dependencies between MBeans – Example: • IMPLICIT SCHEME
– I name my xAR in such a way that it is deployed in a particular order. – I list my MBeans in a single xxx-service.xml file, they will be deployed one after the other, sequentially.

• EXPLICIT SCHEME
– In my Mbean definition, I explicitly state that the MBean requires a given DataSource MBean.

Implicit rules are used by default and they can be overridden by explicit definitions

Implicit behavior is defined by:
– URLComparator policy – Russian Doll ordering

Explicit behavior is defined by:
– explicitly stating MBean dependencies in MBean definitions

© JBoss, Inc. 2003-2005

15

Deployment Ordering

- Implicit Rules
Professional Open Source™

– The default deployment-ordering-policy is defined in conf/jboss-service.xml
by the attribute URLComparator set to DeploymentSorter – It can be redefined to PrefixDeploymentSorter by uncommenting the appropriate definition
... <mbean code="org.jboss.deployment.scanner.URLDeploymentScanne r" name="jboss.deployment:type=DeploymentScanner,flavor= URL"> ... <attribute name="URLComparator“ >org.jboss.deployment.DeploymentSorter</attribute> <!-<attribute name="URLComparator“ >org.jboss.deployment.scanner.PrefixDeploymentSorter</att ribute> --> ... </mbean>
© JBoss, Inc. 2003-2005

16

Deployment Ordering

- Implicit Rules : Deployment Sorter
Professional Open Source™

The DeploymentSorter policy defines the following order according to the package type:
• • • • • • • • • • SAR xxx-ds.xml xxx-service.xml RAR JAR WAR WSR EAR ZIP .last (deploy.last in all configuration)

© JBoss, Inc. 2003-2005

17

Deployment Ordering

- Implicit Rules : Prefix Sorter
Professional Open Source™

The PrefixDeploymentSorter policy (not activated by default):
– Defines the order according to the package naming. – If your packages match this naming convention nnn-whatever.xAR where: nnn is a numeric value whatever is any string xAR is any package extension (JAR, WAR, EAR, SAR, etc.) these packages are deployed according to their nnn value (smaller values first). Example: 10-myDataSource-service.xml 20-myEjb.jar – If some packages contain no prefix: • Non-prefixed packages are deployed before prefixed packages • Non-prefixed packages deployment ordering is delegated to the DeploymentSorter

© JBoss, Inc. 2003-2005

18

Deployment Ordering

- Implicit Rules : Russian Dolls
Professional Open Source™

 Independently of the URLComparator you have chosen, what happens when you deploy a Russian Doll packaging?
 INNER FIRST, OUTER LAST

JAR JAR SAR EJB

WAR

In this case: 1° WAR, 2° JAR+EJB, 3° SAR, 4°JAR

© JBoss, Inc. 2003-2005

19

Deployment Ordering

- Explicit Dependencies
Professional Open Source™

 Implicit rules are very simple to use  But sometimes…
– It is not possible to simply express complex dependencies, or… – A more robust mechanism is wanted to express dependencies in complex deployments  EXPLICIT DEPENDENCIES

Explicit Dependencies are always set at the MBean-level

© JBoss, Inc. 2003-2005

20

Deployment Ordering

- Explicit Dependencies
Professional Open Source™

 To define an explicit dependency, you need:
– A source MBean that requires the presence of another MBean – A target MBean ObjectName

 An explicit dependency states the list of target MBeans that must be started before a given source MBean can be started.  As long as the list of dependencies is not satisfied, the MBean is not created/started.

© JBoss, Inc. 2003-2005

21

Deployment Ordering

- Explicit Dependencies : Example
Professional Open Source™

Let’s say that we have a mycompany-service.xml file deployed in /deploy
<mbean code=“com.mycompany.WhateverClass" name=“mycompany:service=HighLevelService" > <depends>mycompany:service=BaseService</ depends> </mbean> ... <mbean code=“com.mycompany.CoreClass" name=“mycompany:service=BaseService"> – The implicit order would first create HighLevelService and then </mbean> BaseService (because MBeans are started in the sequence in which they are defined) – However, as an explicit dependency is defined (<depends> tag), the implicit behavior is overridden and BaseService is created before HighLevelService

© JBoss, Inc. 2003-2005

22

Deployment Ordering

– deploy-hasingleton directory
Professional Open Source™

 In the server configuration ‘all’, the deploy-hasingleton directory (at the same level as the deploy and farm directories) contains services that are deployed on exactly one node in the cluster.  Its lifecycle is controlled by the jboss.ha:service=HASingletonDeployer Mbean service, defined in the deploy\deploy-hasingleton-service.xml.  The deploy-hasingleton directory contains services such as HAJMS,
designed to run the JMS server on a single node in a clustered environment.

 If the node on which the singleton services are currently deployed fails, they will be automatically redeployed on another available node in the cluster.

© JBoss, Inc. 2003-2005

23

Deployment Ordering

– /deploy-last directory
Professional Open Source™

 The /deploy-last directory is a container of directories or files ending in ".last ", to be deployed after everything has been deployed in /deploy.  For instance, this is the case for the farm service, where every other component has to be started before the deployment of the /farm directory.  The folder named "deploy.last" contains farm-service.xml describing the farm service.

© JBoss, Inc. 2003-2005

24

Deployment Ordering

– /farm directory
Professional Open Source™

 JBoss farming features allows you to deploy any packaged service/application on all nodes of a cluster by copying a file in the /farm folder on one of the nodes.

© JBoss, Inc. 2003-2005

25

Deployment Ordering

- Lab
Professional Open Source™

 Deployment Ordering Lab
 (lab-order)

© JBoss, Inc. 2003-2005

26

Professional Open Source™

Advanced Installation

Multiple Nodes

© JBoss, Inc. 2003-2005.

October 14, 2008

27

Multiple Nodes

– Introduction
Professional Open Source™

It is often necessary to run several JBoss instances on the same host:
– If the developer’s workstation is overloaded or has low performance – If the instance needs a local specific “service”

In that case, each JBoss instance must:
– Have its own set of writable directories (/tmp, /data, /log, /deploy) and share some common configuration and deployment directories (/conf, /lib, /deploy-common) – Have its own JBoss configuration (read and write directories) – Be identified by a unique “IPaddress/Port” to avoid IP/Port conflicts • Each JBoss service (Mbean) listening on a port, defines the “Port” and “BindAddress” attributes. • By default, “BindAddress” is unspecified, taking the value “0.0.0.0”, meaning that it can be bound to all interfaces of a multi-homed machine.

© JBoss, Inc. 2003-2005

28

Multiple Nodes –

Unique IP/Port Configuration: Manual Solution
Professional Open Source™

Modify manually the IP/Port configuration for each JBoss instance. Problems:
– Many configuration files to modify in several configurations. – Some configuration files are hidden in packages (xxx.sar). It is necessary to unpackage, modify, re-package. – This has to be done again when upgrading to a new version of Jboss Server. – This is not possible if using a single base configuration for all developers.

Solution:
– Define the IP/Port configurations as system properties in all JBoss configuration files.

© JBoss, Inc. 2003-2005

29

Multiple Nodes –

Unique IP/Port Configuration: Multi-Homing
Professional Open Source™

Multi-homing consists in defining several IP addresses associated to a machine’s network interface (NIC):
– Each IP address will be allocated to a unique JBoss Server instance – Each JBoss instance will be launched using the “-b IP@” or “—host” switch of the “run” command – Ports can have the same value for all JBoss instances /usr/local/jboss/bin/run.sh –b 192.168.1.101 /usr/local/jboss/bin/run.sh –b 192.168.1.102 or /usr/local/jboss/bin/run.sh --host 192.168.1.101 /usr/local/jboss/bin/run.sh --host 192.168.1.102

© JBoss, Inc. 2003-2005

30

Multiple Nodes –

Unique IP/Port Configuration: ServiceBinding
Professional Open Source™

The BindingManager is a service (Mbean):
– Defined in conf/jboss-service.xml, and not activated by default. The following section must be commented out. – Queried for completion of the Mbean attributes in the service’s configuration file, for each service (Mbean) started, by overriding these attributes on the fly. • In our case, we will use the BindingManager to override the default IP/Port settings: each user will have its own BindingManager configuration. – The BindingManager is backed by a configuration file including several sets of configurations.

© JBoss, Inc. 2003-2005

31

Multiple Nodes –

Unique IP/Port Configuration: ServiceBindingManager
Professional Open Source™

© JBoss, Inc. 2003-2005

32

Multiple Nodes – Unique IP/Port Configuration: ServiceBinding Configuration
Professional Open Source™

The BindingManager uses an XML configuration file, jboss-bindings.xml :
– – – Each <server> section defines the configuration for a given server. Each server configuration is composed by a set of <service-config> sub-sections, each configuring a particular service. Each <service-config> sub-section makes use of a particular engine to modify the value of an attribute, before the Mbean is started: • One engine, AttributeMappingDelegate, simply overrides the value of an attribute, • Another engine, XSLTConfigDelegate, applies an XSLT transformation to the value of an XML attribute, • You can develop your own engine, if necessary. A more complete example of a BindingManager configuration file can be found in the Jboss source code in: jboss-all/testsuite/src/cluster-test/jboss-bindings.xml. This configuration is used for testing the clustering feature (two nodes running on the same host).

© JBoss, Inc. 2003-2005

33

Multiple Nodes –

ServiceBindingManager Configuration DTD
Professional Open Source™

© JBoss, Inc. 2003-2005

34

Multiple Nodes

- Lab
Professional Open Source™

 Multiple Nodes
 (lab-multihome)

© JBoss, Inc. 2003-2005

35

Sign up to vote on this title
UsefulNot useful