This chapter describes Java Message Service (JMS) and Java Transaction API (JTA) high availability.
This chapter includes the following topics:
Section 6.1, "About JMS and JTA Services for High Availability"
Section 6.2, "Configuring JMS and JTA Services for High Availability"
Section 6.4, "Considerations for Using File Persistence (WebLogic JMS)"
Section 6.5, "Configuring WLS JMS with a Database Persistent Store"
Section 6.6, "Configuring Database Stores to Persist Transaction Logs"
See Also:
For more information on working with JMS or JTA, see one of the following topics:
"Configuring WebLogic JMS Clustering" in the guide Oracle Fusion Middleware Administering JMS Resources for Oracle WebLogic Server
"Interoperating with Oracle AQ JMS" in the guide Oracle Fusion Middleware Administering JMS Resources for Oracle WebLogic Server
"Configuring JTA" in the guide Developing JTA Applications for Oracle WebLogic Server.
"Domains:Configuration:JTA" and "Cluster:Configuration:JTA" in the Administration Console Online Help
Java Message Service (JMS) is an application program interface (API) that supports the formal communication known as messaging between computers in a network.
Java Transaction API (JTA) specifies standard Java interfaces between a transaction manager and the parties involved in a distributed transaction system: the resource manager, the application server, and the transactional applications.
In WebLogic JMS, a message is available only if its host JMS server for the destination is running. If a message is in a central persistent store, the only JMS server that can access the message is the server that originally stored the message. WebLogic includes features for automatically restarting and/or migrating a JMS server after a failure. It also includes features for clustering (distributing) a destination across multiple JMS servers within the same cluster.
You automatically restart and / or migrate (fail over) JMS Servers using either Whole Server Migration or Automatic Service Migration.
See Also::
For more information on Whole Server Migration, see Chapter 3, "Whole Server Migration."
You can configure JMS and JTA services for high availability by using a migratable target, a special target that can migrate from one server in a cluster to another. A migratable target provides a way to group migratable services that should move together. When a migratable target migrates, all services the target hosts also migrate.
To configure a JMS service for migration, you must deploy it to a migratable target. The migratable target specifies a set of servers that can host a target, and can specify a user-preferred host for the services and an ordered list of candidate backup servers if the preferred server fails. Only one server can host the migratable target at any one time.
After you configure a service to use a migratable target, the service is independent from the server member that is currently hosting it. For example, if a JMS server with a deployed JMS queue is configured to use a migratable target then the queue is independent of when a specific server member is available. That is, the queue is always available when the migratable target is hosted by any server in the cluster.
You can migrate pinned migratable services manually from one server instance to another in the cluster if a server fails or as part of regularly scheduled maintenance. If you do not configure a migratable target in the cluster, migratable services can migrate to any WebLogic Server instance in the cluster.
See Also:
For more information on administering JMS, see the guide Oracle Fusion Middleware Administering JMS Resources for Oracle WebLogic Server, which includes the following topics:
When you deploy a JMS service to the migratable target, you can select a user-preferred server target to host the service. When configuring a migratable target, you can also specify constrained candidate servers (CCS) that can host the service if the user-preferred server fails. If the migratable target does not specify a constrained candidate server, you can migrate the JMS server to any available server in the cluster.
WebLogic Server enables you to create separate migratable targets for JMS services. This allows you to always keep each service running on a different server in the cluster, if necessary. Conversely, you can configure the same selection of servers as the constrained candidate servers for both JTA and JMS, to ensure that the services remain co-located on the same server in the cluster.
See Also:
For more information, see the following topics in the Administration Console Online Help:
"Configure migratable targets for JMS-related services"
"Configure migratable targets for the JTA Transaction Recovery Service"
You can configure JMS messages and JTA logs to be stored on the file system. For high availability, you must use a shared file system. See Chapter 4, "Using Shared Storage" for information on what to consider when using a shared file system to store these artifacts.
See Also:
For more information see "WebLogic JMS Architecture and Environment" in the guide Administering JMS Resources for Oracle WebLogic Server.
If you store JMS messages and transaction logs on an NFS-mounted directory, Oracle strongly recommends that you verify the behavior of a server restart after an abrupt machine failure. Depending on the NFS implementation, different issues can arise after a failover/restart.
To verify server restart behavior, abruptly shut down the node that hosts WebLogic servers while the servers are running.
If you configured the server for server migration, it should start automatically in failover mode after the failover period.
If you did not configure the server for server migration, you can manually restart the WebLogic Server on the same host after the node completely reboots.
If Oracle WebLogic Server does not restart after abrupt machine failure, verify whether or not it is due to an I/O exception that is similar to the following by reviewing the server log files:
<MMM dd, yyyy hh:mm:ss a z> <Error> <Store> <BEA-280061> <The persistent store "_WLS_server_1" could not be deployed: weblogic.store.PersistentStoreException: java.io.IOException: [Store:280021]There was an error while opening the file store file "_WLS_SERVER_1000000.DAT" weblogic.store.PersistentStoreException: java.io.IOException: [Store:280021]There was an error while opening the file store file "_WLS_SERVER_1000000.DAT" at weblogic.store.io.file.Heap.open(Heap.java:168) at weblogic.store.io.file.FileStoreIO.open(FileStoreIO.java:88) ... java.io.IOException: Error from fcntl() for file locking, Resource temporarily unavailable, errno=11
This error occurs when the NFSv3 system does not release locks on the file stores. WebLogic Server maintains locks on files that store JMS data and transaction logs to prevent data corruption that can occur if you accidentally start two instances of the same Managed Server. Because the NFSv3 storage device doesn't track lock owners, NFS holds the lock indefinitely if a lock owner fails. As a result, after abrupt machine failure followed by a restart, subsequent attempts by WebLogic Server to acquire locks may fail.
How you resolve this error depends on your NFS environment: (See Oracle Fusion Middleware Release Notes for updates on this topic.)
For NFSv4 environments, you can set a tuning parameter on the NAS server to release locks within the approximate time required to complete server migration; you do not need to follow the procedures in this section. See your storage vendor's documentation for information on locking files stored in NFS-mounted directories on the storage device, and test the results.
For NFSv3 environments, the following sections describe how to disable WebLogic file locking mechanisms for: the default file store, a custom file store, a JMS paging file store, a diagnostics file store.
WARNING:
NFSv3 file locking prevents severe file corruptions that occur if more than one Managed Server writes to the same file store at any point in time.
If you disable NFSv3 file locking, you must implement administrative procedures /policies to ensure that only one Managed Server writes to a specific file store. Corruption can occur with two Managed Servers in the same cluster or different clusters, on the same node or different nodes, or on the same domain or different domains.
Your policies could include: never copy a domain, never force a unique naming scheme of WLS-configured objects (servers, stores), each domain must have its own storage directory, no two domains can have a store with the same name that references the same directory.
When you use a file store, always configure the database-based leasing option for server migration. This option enforces additional locking mechanisms using database tables and prevents automated restart of more than one instance of a particular Managed Server.
Disabling File Locking for the Default File Store
To disable file locking for the default file store using the Administration Console:
If necessary, click Lock & Edit in the Change Center (upper left corner) of the Administration Console to get an Edit lock for the domain.
In the Domain Structure tree, expand the Environment node and select Servers.
In the Summary of Servers list, select the server you want to modify.
Select the Configuration > Services tab.
Scroll down to the Default Store section and click Advanced.
Scroll down and deselect the Enable File Locking check box.
Click Save. If necessary, click Activate Changes in the Change Center.
Restart the server you modified for the changes to take effect.
The resulting config.xml entry looks like the following:
<server>
<name>examplesServer</name>
...
<default-file-store>
<synchronous-write-policy>Direct-Write</synchronous-write-policy>
<io-buffer-size>-1</io-buffer-size>
<max-file-size>1342177280</max-file-size>
<block-size>-1</block-size>
<initial-size>0</initial-size>
<file-locking-enabled>false</file-locking-enabled>
</default-file-store>
</server>
Disabling File Locking for a Custom File Store
To disable file locking for a custom file store using the Administration Console:
If necessary, click Lock & Edit in the Change Center (upper left corner) of the Administration Console to get an Edit lock for the domain.
In the Domain Structure tree, expand the Services node and select Persistent Stores.
In the Summary of Persistent Stores list, select the custom file store you want to modify.
On the Configuration tab for the custom file store, click Advanced.
Scroll down and deselect the Enable File Locking check box.
Click Save. If necessary, click Activate Changes in the Change Center.
If the custom file store was in use, you must restart the server for the changes to take effect.
The config.xml entry looks like the following example:
<file-store>
<name>CustomFileStore-0</name>
<directory>C:\custom-file-store</directory>
<synchronous-write-policy>Direct-Write</synchronous-write-policy>
<io-buffer-size>-1</io-buffer-size>
<max-file-size>1342177280</max-file-size>
<block-size>-1</block-size>
<initial-size>0</initial-size>
<file-locking-enabled>false</file-locking-enabled>
<target>examplesServer</target>
</file-store>
Disabling File Locking for a JMS Paging File Store
To disable file locking for a JMS paging file store using the Administration Console:
If necessary, click Lock & Edit in the Change Center (upper left corner) of the Administration Console to get an Edit lock for the domain.
In the Domain Structure tree, expand the Services node, expand the Messaging node, and select JMS Servers.
In the Summary of JMS Servers list, select the JMS server you want to modify.
On the Configuration > General tab for the JMS Server, scroll down and deselect the Paging File Locking Enabled check box.
Click Save. If necessary, click Activate Changes in the Change Center.
Restart the server you modified for the changes to take effect.
The config.xml file entry will look like the following example:
<jms-server>
<name>examplesJMSServer</name>
<target>examplesServer</target>
<persistent-store>exampleJDBCStore</persistent-store>
...
<paging-file-locking-enabled>false</paging-file-locking-enabled>
...
</jms-server>
Disabling File Locking for a Diagnostics File Store
To disable file locking for a Diagnostics file store using the Administration Console:
If necessary, click Lock & Edit in the Change Center (upper left corner) of the Administration Console to get an Edit lock for the domain.
In the Domain Structure tree, expand the Diagnostics node and select Archives.
In the Summary of Diagnostic Archives list, select the server name of the archive that you want to modify.
On the Settings for [server_name] page, deselect the Diagnostic Store File Locking Enabled check box.
Click Save. If necessary, click Activate Changes in the Change Center.
Restart the server you modified for the changes to take effect.
The resulting config.xml file will look like this:
<server> <name>examplesServer</name> ... <server-diagnostic-config> <diagnostic-store-dir>data/store/diagnostics</diagnostic-store-dir> <diagnostic-store-file-locking-enabled>false</diagnostic-store-file-locking- enabled> <diagnostic-data-archive-type>FileStoreArchive</diagnostic-data-archive-type> <data-retirement-enabled>true</data-retirement-enabled> <preferred-store-size-limit>100</preferred-store-size-limit> <store-size-check-period>1</store-size-check-period> </server-diagnostic-config> </server>
See Also:
For more information, see one of the following topics:
"Configure JMS Servers and Persistent Stores" in Oracle Fusion Middleware Administering JMS Resources for Oracle WebLogic Server.
"Using the WebLogic Persistent Store" in Oracle Fusion Middleware Configuring Server Environments for Oracle WebLogic Server.
The persistent store provides a built-in, high-performance storage solution for WebLogic Server subsystems and services that require persistence. For example, it can store persistent JMS messages.
The WLS JMS persistent store supports persistence to a file-based store or to a JDBC-accessible store in a database. This topic describes how to change the WLS JMS configuration from a file-based persistent store (the default configuration) to a database persistent store.
For information on the persistent store, see "Using the WebLogic Persistent Store" in the guide Administering Server Environments for Oracle WebLogic Server.
For information on the typical tasks you need to monitor, control and configure WebLogic messaging components, see "WebLogic Server Messaging" in the guide Administering Oracle WebLogic Server with Fusion Middleware Control.
This section includes the following topics:
Section 6.5.1, "Prerequisites for Configuring WLS JMS with a Database Persistent Store"
Section 6.5.2, "Switching WLS JMS File-Based Persistent Stores to Database Persistent Store"
Section 6.6, "Configuring Database Stores to Persist Transaction Logs"
To configure WLS JMS with database persistent stores, verify that your setup meets the following requirements:
An Oracle Fusion Middleware installation with at least one cluster and one or more JMS servers
JMS servers that use file persistent stores, the default configuration.
This section describes the steps for switching to a database-based persistent store for WLS JMS from the default file-based persistent store.
You must follow the steps in this procedure for each JMS server that you must configure to use database persistent stores.
Create a JDBC store. See "Using a JDBC Store" in the guide Oracle Fusion Middleware Administering Server Environments for Oracle WebLogic Server for detailed steps.
Note:
You must specify a prefix to uniquely name the database table for the JDBC store.
Associate the JDBC store with the JMS server:
In the Weblogic Server Administration Console, go to Services->Messaging->JMS Servers.
Verify that there are no pending messages in this server. In the Control tab, stop production and insertion of messages for all destinations and wait for any remaining messages to drain.
Select the General Configuration tab. Under Persistent Store, select the new JDBC store then click Save.
The JMS server starts using the database persistent store.
This section describes the steps to configure database-based stores for the Transaction Logs (TLOGs). Before you configure a JDBC TLOG Store, you must have a standard Oracle Fusion Middleware installation.
After a standard installation, the TLOG Store is configured to be in the file system. In some instances, Oracle recommends that you configure the TLOGs to be stored in the database.
To configure the JDBC TLOGs to be stored in the database store, see the detailed steps in "Using a JDBC TLOG Store" in the guide Oracle Fusion Middleware Administering Server Environments for Oracle WebLogic Server.
Note the following:
You must repeat the procedure for each Managed Server in the cluster.
Use the Managed Server name as a prefix to create a unique TLOG store name for each Managed Server.
For a high availability setup, verify that the data source that you created for the persistent store is targeted to the cluster.
When you complete the configuration, TLOGs are directed to the configured database-based persistent store.
Note:
When you add a new Managed Server to a cluster by scaling up or scaling out, you must also create the corresponding JDBC TLOG Store for the new Managed Server.