9-4 Configuring and Managing JMS for Oracle WebLogic Server
9.3 Integration and Multi-Domain Best Practices
The following section provides best practice information for integration and multi-domain environments using WebLogic Server:
■
For server side applications that communicate with destinations in a remote WebLogic cluster or server, see Integrating Remote JMS Providers in
Programming JMS for Oracle WebLogic Server.
■
Interoperating WebLogic Server domains have the following restrictions:
– Domain names must be unique.
– WebLogic server names must be unique, even if they are in two different
domains.
– JMS server names must be unique, even if they are in two different domains.
– Interoperating domains may have special Security considerations.
■
For applications that interoperate with AQ JMS, see Section 7, Interoperating with
Oracle AQ JMS.
9.4 Understanding WebLogic JMS Client Options
For client applications applications that have a runtime environment independent of WebLogic Server there are multiple JMS client options, including: Java, .NET, and C
clients. See JMS Clients in Programming Stand-alone Clients for Oracle WebLogic Server.
9.5 Understanding WebLogic URLs
Applications that are communicating with a remote WebLogic Server instance or cluster must specify a URL when creating their JNDI InitialContext objects andor
setting application attributes in order to connect to a server or a cluster.
■
Do not specify URLs for applications that run on the same server or cluster as their JMS resources. When an initial context is created without specifying URLs, it
automatically references the local server or cluster JNDI.
■
If a URL resolves to multiple addresses, WebLogic Server clients will randomly select an address in the list to start with and then automatically try each address in
turn until one succeeds.
■
In production systems, consider using DNS round robin or a hardware load balancer for initial hostname resolution rather than using the multiple hostport
URL notation shown in Section 9.5.1, URL syntax.
9.5.1 URL syntax
The WebLogic URL syntax is: [t3|t3s|http|https|iiop|iiops]:address[,address]...
where
■
address = hostlist : portlist
Note: WebLogic JMS clients do not directly support foreign
transaction managers. Use the WebLogic TM if possible. For advanced users, the transaction subsystem Interposed Transaction Manager
feature may be used as an XA resource.
Best Practices for JMS Beginners and Advanced Users 9-5
■
hostlist = hostname [,hostname]...
■
portlist = portrange [+portrange]...
■
portrange = port [-port] Use port-port to indicate a port range, and + to separate multiple port ranges. For
example, a simple address is typically something like t3:hostA:7001; the address t3:hostA,hostB:7001-7002 is equivalent to the following addresses.
■
t3:hostA,hostB:7001+7002
■
t3:hostA:7001-7002,hostB:7001-7002
■
t3:hostA:7001+7002,hostB:7001+7002
■
t3:hostA:7001,hostA:7002,hostB:7001,hostB:7002
9.6 Strict Message Ordering Best Practices
If strictly ordered message processing is required, then application design and configuration needs to carefully take this requirement into account.
The simplest and most capable option is to leverage the WebLogic JMS Unit-of-Order feature. This option normally requires minimal or even no changes to applications,
plus it works with distributed destinations, scheduled messages, delayed messages, transactions, and store-and-forward. See Using Message Unit-of-Order in
Programming JMS for Oracle WebLogic Server.
9.7 High Availability Best Practices
If High Availability HA or scalability is a concern, develop applications so that they leverage clustered WebLogic features. This approach is best taken in the early
configuration and application design stage as it is usually difficult process to change a non-clustered application into a clustered application.
In WebLogic JMS, a message is only available 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 andor migrating a JMS server after a failure. It
also includes features for clustering distributing a destination across multiple JMS servers within the same cluster.
HA is normally accomplished using both:
■
Distributed destinations
■
HA ServersServices. JMS Servers can be automatically restarted andor migrated using either Whole Server Migration or Automatic Service Migration.
9.7.1 Distributed Queues vs Distributed Topics
Distributed queues are generally fairly easy to apply to an arbitrary clustered queueing use case. Distributed topics have a series of fundamental limitations that can
restrict their applicability.
9.8 JMS Performance and Tuning
The following section provides a link to a checklist of items to consider when tuning WebLogic JMS:
9-6 Configuring and Managing JMS for Oracle WebLogic Server
■
JMS Performance Tuning Check List in Performance and Tuning for Oracle WebLogic Server.
10
Troubleshooting WebLogic JMS 10-1
10
Troubleshooting WebLogic JMS
This release of WebLogic Server includes the WebLogic Diagnostic Service, which is a monitoring and diagnostic service that runs within the WebLogic Server process and
participates in the standard server life cycle. This service enables you to create, collect, analyze, archive, and access diagnostic data generated by a running server and the
applications deployed within its containers. This data provides insight into the runtime performance of servers and applications and enables you to isolate and
diagnose faults when they occur. WebLogic JMS takes advantage of this service to provide enhanced runtime statistics, notifications sent to queues and topics, message
life cycle logging, and debugging to help you keep your WebLogic domain running smoothly.
For more information on monitoring JMS statistics and managing JMS messages, see Chapter 8, Monitoring JMS Statistics and Managing Messages.
The following sections explain how to troubleshoot WebLogic JMS messages and configurations:
■
Section 10.1, Configuring Notifications for JMS