5 JMS and JTA High Availability

This chapter describes Java Message Service (JMS) and Java Transaction API (JTA) high availability.

This chapter includes the following topics:

See Also:

For more information on working with JMS or JTA, see one of the following topics:

5.1 About JMS and JTA Services for High Availability

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.

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.

5.2 Configuring JMS and JTA Services for High Availability

To configure a migratable 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 manually migrate pinned migratable services 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.

5.3 User-Preferred Servers and Candidate Servers

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"

5.4 Considerations for Using File Persistence (WebLogic JMS)

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 3, "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.

5.4.1 Considerations for Using File Stores on NFS

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.

If you configure a Managed Server using a file store for server migration, always configure the database- based leasing option. 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:

  1. If necessary, click Lock & Edit in the Change Center (upper left corner) of the Administration Console to get an Edit lock for the domain.

  2. In the Domain Structure tree, expand the Environment node and select Servers.

  3. In the Summary of Servers list, select the server you want to modify.

  4. Select the Configuration > Services tab.

  5. Scroll down to the Default Store section and click Advanced.

  6. Scroll down and deselect the Enable File Locking check box.

  7. Click Save. If necessary, click Activate Changes in the Change Center.

  8. 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:

  1. If necessary, click Lock & Edit in the Change Center (upper left corner) of the Administration Console to get an Edit lock for the domain.

  2. In the Domain Structure tree, expand the Services node and select Persistent Stores.

  3. In the Summary of Persistent Stores list, select the custom file store you want to modify.

  4. On the Configuration tab for the custom file store, click Advanced.

  5. Scroll down and deselect the Enable File Locking check box.

  6. Click Save. If necessary, click Activate Changes in the Change Center.

  7. If the custom file store was in use, you must restart the server for the changes to take effect.

The resulting config.xml entry looks like the following:

  <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:

  1. If necessary, click Lock & Edit in the Change Center (upper left corner) of the Administration Console to get an Edit lock for the domain.

  2. In the Domain Structure tree, expand the Services node, expand the Messaging node, and select JMS Servers.

  3. In the Summary of JMS Servers list, select the JMS server you want to modify.

  4. On the Configuration > General tab for the JMS Server, scroll down and deselect the Paging File Locking Enabled check box.

  5. Click Save. If necessary, click Activate Changes in the Change Center.

  6. Restart the server you modified for the changes to take effect.

The resulting config.xml file entry will look like the following:

  <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:

  1. If necessary, click Lock & Edit in the Change Center (upper left corner) of the Administration Console to get an Edit lock for the domain.

  2. In the Domain Structure tree, expand the Diagnostics node and select Archives.

  3. In the Summary of Diagnostic Archives list, select the server name of the archive that you want to modify.

  4. On the Settings for [server_name] page, deselect the Diagnostic Store File Locking Enabled check box.

  5. Click Save. If necessary, click Activate Changes in the Change Center.

  6. 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:

5.5 Configuring Schemas for Transactional Recovery Privileges

You need the appropriate database privileges to enable the WebLogic Server transaction manager to:

  • Query for transaction state information

  • Issue the appropriate commands, such as commit and rollback, during recovery of in-flight transactions after a WebLogic Server container failure.

To configure the schemas for transactional recovery privileges:

  1. Log on to SQL*Plus as a user with sysdba privileges. For example:

    sqlplus "/ as sysdba"
    
  2. Grant select on sys.dba_pending_transactions to the appropriate_user.

  3. Grant force any transaction to the appropriate_user.