Enable Debugging Using the WebLogic Scripting Tool

Use the WebLogic Scripting Tool (WLST) to set the debugging values. For example,
the following command runs a program for setting debugging values called
debug.py:


java weblogic.WLST debug.py


The main scope, weblogic, does not appear in the graphic; jms is a sub-scope within
weblogic. Note that the fully-qualified DebugScope for DebugJMSBackEnd is
weblogic.jms.backend.
The debug.py program contains the following code:


user='user1'
password='password'
url='t3://localhost:7001'
connect(user, password, url)

edit()
cd('Servers/myserver/ServerDebug/myserver')
startEdit()
set('DebugJMSBackEnd','true')
save()
activate()


Note that you can also use WLST from Java. The following example shows a Java file used to set debugging values:





import weblogic.management.scripting.utils.WLSTInterpreter;
import java.io.*;
import weblogic.jndi.Environment;
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;
public class test {
public static void main(String args[]) {
try {
WLSTInterpreter interpreter = null;
String user="user1";
String pass="pw12ab";
String url ="t3://localhost:7001";
Environment env = new Environment();
env.setProviderUrl(url);
env.setSecurityPrincipal(user);
env.setSecurityCredentials(pass);
Context ctx = env.getInitialContext();
interpreter = new WLSTInterpreter();
interpreter.exec
("connect('"+user+"','"+pass+"','"+url+"')");
interpreter.exec("edit()");
interpreter.exec("startEdit()");
interpreter.exec
("cd('Servers/myserver/ServerDebug/myserver')");
interpreter.exec("set('DebugJMSBackEnd','true')");
interpreter.exec("save()");
interpreter.exec("activate()");
} catch (Exception e) {
System.out.println("Exception "+e);
}
}
}



Using the WLST is a dynamic method and can be used to enable debugging while the
server is running.

Configure a JMS Module

A homogenous set of JMS servers is either a single JMS server that is meant to host non-distributed destinations, or a set of similarly configured JMS servers that each host the same distributed destination. Configure a JMS module and a single associated subdeployment for each homogenous set of JMS servers:

1. Create a system module. Target it to a single cluster (if using clusters) or a single WebLogic Server instance. You must always target the module even when leveraging subdeployments.

It is almost always preferable to use system modules instead of deployable

application modules. System modules can be created using the administration

console, the JMX API (Java MBeans), or WLST, there is no equivalent tooling for deployable modules. The only way to modify deployable modules is to manually edit the XML and redeploy.

2. Create exactly one subdeployment per module. Subdeployments are sometimes referred to as "advanced targeting" on the administration console. A single subdeployment aids simplicity - it's much easier for third parties to understand the targeting, and it reduces the chances of making configuration errors. If a single subdeployment is not sufficient, create two modules.

3. Populate the subdeployment only with JMS servers - not WebLogic servers. Only include the JMS servers that you wish to host destinations. This ensures that when the JMS resources are configured, they are targeted to the correct JMS servers. For modules that support non-distributed destinations, the subdeployment must only reference a single JMS Server. If you have a mix of distributed and non-distributed destinations, use two modules each with its own subdeployment.

Configure JMS Servers and Persistent Stores

1. Create a custom store on each WebLogic server that will host a JMS server. If there's already a custom store on a WebLogic server, you can skip this step as its usually more convenient and more performant for services to share a store. (Why use a custom store? Custom stores provide more flexibility in tuning and administration. In addition, the default file store is not migratable -- only custom stores are migratable.)

2. In a cluster, target each store to its host server's "default migratable target". If you have decided not to use a cluster, target each store directly to its host server. Migratable targets enable restart-in-place options on a store failure, and also enable service migration options.

It is recommended to always target to migratable targets when available (instead of direct server targets). Migratable targets are compatible with the whole server migration option, and usually should be configured even when whole server migration is the primary fail-over option.

3. Configure a JMS server on each WebLogic server. Configure the JMS server to reference the store that was created in step 1. Target the JMS server to the same target that was used for the store. Multiple JMS servers can reference the same store.

4. Configure message count quotas on each JMS server. There is no default quota, so configuring one helps protect against out-of-memory conditions. Rule of thumb:

conservatively assume that each message consumes 512 bytes of memory even if it is paged out.

5. Although JMS paging is enabled by default, verify that the default behavior is valid for your environment.