ODR Problem Determination

documentOn Demand Router common problemsA Step-by-Step guide to troubleshoot

Delivered: Jan 29, 2010

Created for: Wal-Mart (WebSphere Infrastructure Support)

Author:

Premium Support Analysts /XD Team

1 4/22/2023

2 4/22/2023

Table of Contents

1 Business Objectives....................................................................................................3

2 The role of ODR.........................................................................................................3

3 ODR JVM setting......................................................................................................3

4 ODR stop,start and diagnostic files..........................................................................4

5 Common Problems....................................................................................................4

7 ODR Tracing............................................................................................................13

8 Bypass ODR.............................................................................................................16

9 ODR Resources.........................................................................................................17

3 4/22/2023

1 Business ObjectivesThe objectives of this document are to address several of the most common problems observed by IBM Premium Support Analysts while supporting ODR, to help Wal-Mart engineers avoid unnecessary outages, respond to common problems efficiently, enhance customer skills, share lessons learned and provide great tips. This document also provides step-by-step guidance for resolution of common problems and links to IBM resources for WebSphere Virtual Enterprise On-Demand Router (ODR).

2 The role of ODRODR is an intelligent HTTP and Session Initiation Protocol (SIP) proxy server in WebSphere Virtual Enterprise that possesses advanced routing and proxy capabilities. The ODR is the point of entry into a WebSphere Virtual Enterprise environment and is a gateway through which HTTP requests and Session Initiation Protocol (SIP) messages flow to back-end application servers. You can configure the ODR to determine how it handles failure scenarios and how it tunes certain work requests.

3 ODR JVM settingsBecause ODR is a type of application server, the JVM heap size is an important consideration in tuning ODR. Allocate adequate heap size to ensure that the ODR is capable of handling client requests and keeping track of sessions. ODR generates an estimated 4 - 5KB of transitory data objects per request. Administrators can calculate and set the minimum and maximum heap sizes by using estimates of the number of client requests across available ODR instances and the size of message requests. The ODR base footprint is 90MB.

4 4/22/2023

4 ODR commands and diagnostic filesODR Commands location:

$WAS_HOME/profiles/< ODR_ProfileName>/bin

To find out ODR JVMInstance process IDps –ef | grep ODR_JVMInstance

./stopServer.sh ODR_name

./startServer.sh ODR_name

ODR logs location

$WAS-HOME/profile/ODR_ProfileName/logs/ODR_JVMInstance

Proxy.log The ODR routes Http requests to remote servers. The responses from those servers are logged here. If the ODR receives a request and routes it, there will be an entry in this log file provided the remote server has responded.

FFDC (First Failure Data Capture)These files (in the logs/ffdc directory) capture incident information when WebSphere detects an internal exception. The log will contain the exception, stack trace and contents of the respective class. Local.logAll local (local to the ODR) non-cached responses are logged here. These can be redirects or internal errors. Look in this log file if it appears the ODR is not routing to a remote server. The ODR will not route a request unless it recognizes an up and running remote server that is configured to handle the request. You can expect to see an entry in this log file with an http 503 return code if the ODR recognizes that there is a remote server to handle the request, but the server is not up and running. You can expect to see an entry with an http 404 return code if the ODR does not recognize that there is a remote server configured to handle the request.

Note that an entry will appear in local.log with a 404 return code if the Virtual Host of the target application is not configured to work with the ODR. A Host Alias must exist for the ODR (use the ODR PROXY_HTTP_ADDRESS (non-secure) and/or PROXY_HTTPS_ADDRESS (secure) ports for the aliases) that is associated with the Virtual Host for the target application. Normally, the ODR ports are 80 and 443. And, by default, there are Host Aliases for those ports for the default_host Virtual Host. So, if you are using the default_host for your application and your ODR ports are 80 and 443, you shouldn’t have to add any aliases.

5 4/22/2023

If you are experiencing http 302 return codes in the local.log file it’s possible that you have not configured the ODR to “trust” the Web Server. This can happen when running the ODR as non-root. Go the the XD Information Center and search on “trusted web server” to see how this configuration is done. You can also search the WAS Information Center for “trusted web server”, but the XD Info Center gives a better description.

An alternative to configuring the ODR to “trust” the Web Server to resolve 302 return codes, is to configure “Rewriting rules” for the ODR. This is another ODR feature inherited from the WAS Proxy Server. So, to find information on how to configure this, go the the WAS Information Center and search on “Rewriting rules configuration”.

A particular request will appear in only one of the log files. So, you may have to look in all three to determine if the request was received. If the request doesn’t appear any of the log files, one of four things has happened:

The ODR did not receive the request.

This can happen if the host name or port number for the ODR is incorrect on the request. The port to use is the PROXY_HTTP_ADDRESS (non-secure) or PROXY_HTTPS_ADDRESS (secure).

The ODR received the request, has routed the request to a remote server but has not (yet) received a response.

If you think this may have happened, there are a couple of things to do. First, check the ODR outbound request timeout setting (Servers -> On Demand Routers -> ODR Name -> On Demand Router Properties -> On Demand Router settings -> Outbound request timeout). It’s possible that the ODR has routed the request, the remote server hasn’t responded and you have checked the log file before the request has timed out. An entry will not be made in an access log until the ODR returns to the client.

You can verify that the ODR has received and routed a request by configuring ODR tracing. Refer to the next section of this document where it shows how to enable the trace and shows an example trace of a routed request.

The ODR has received the request, but a defect in the ODR has prevented the request from being logged.

This is a very unlikely possibility, but not out of the question. If you think this may be happening, configure ODR tracing (refer to the next section of this document) and verify that the request was received by the ODR and routed.

Access logging has been disabled in the ODR settings.

Access logging is enabled for the ODR by default. Check this setting by going to

6 4/22/2023

Servers->On Demand Routers -> ODR Name -> On Demand Router Properties -> On Demand Router settings -> Logging -> Enable access logging.

The access logging settings can be changed at the ODR settings page (Servers->On Demand Routers -> ODR Name -> On Demand Router Properties -> On Demand Router settings -> Logging -> Enable access logging). On this page you can also configure the maximum size of the access log plus the names and locations of the log files.

Note that you may see access log configuration settings associated with the web container (Servers->On Demand Routers -> ODR Name -> Container Settings -> Web Container Settings -> Web container transport chains -> WCInboundDefault -> HTTP inbound channel (HTTP 1)). The Enable access and error logging setting and any configuration settings from Related Items -> HTTP error and NCSA access logging have no affect on the ODR access logging. So, one result of this is that the access logging format for the ODR cannot be configured for NCSA combined as it can for the WAS internal http servers.

5 Common Problems

1 HTTP Response Code 404

SymptomA 404 means the requested resource was not found.  The URL does not match any application known to the ODR.

Analyzing The things of interest are the request's host, port, context root, and URI. The ODR 's target.xml will prove very useful. Using the target.xml, first check that a vhost exists that corresponds to the requested URL's host and port. If they match, then look at the web modules linked to this vhost. Those are the applications which the request may be mapped to.

 <vHostGroup name="default_host"> <!-- vHost section --> <vHost name="myhost.com:9098"> <property name="port" priority="0" value="9098"/> </vHost> <vHost name="*:80"> <property name="port" priority="0" value="80"/> </vHost> <!-- webModule section --> <link name="/cell/dabtcCell07/application/dabtcNode03/odr1/GenericApplication/webModule/Default_default_host_HTTP_WC"/><link name="/cell/dabtcCell07/application/A/webModule/microwebapp.war"/><link name="/cell/dabtcCell07/application/A/webModule/microsipapp.war"/>

7 4/22/2023

<link name="/cell/dabtcCell07/application/DefaultApplication/webModule/DefaultWebApplication.war"/></vHostGroup>

Now look at each of those available applications, and see if the URI matches any of their context roots and URI patterns. If so, then the 404 may not be appropriate, and ODR must-gather should be analyzed

 <application name="A"> <property name="isWebSphere" value="true"/> <property name="root" priority="0" value="A"/> <property name="edition" priority="0" value=""/> <property name="state" priority="0" value="ACTIVE"/> <!-- webModule section --> <webModule name="microwebapp.war"> <property name="id" priority="0" value="dabtcCell07/A/microwebapp.war"/><property name="contextRoot" priority="0" value="/A"/>                 <property name="fileServingEnabled" priority="0" value="true"/><property name="serveServletsByName" priority="0" value="true"/><property name="protocolMap" priority="0" value="direct"/><property name="routingEnabled" priority="0" value="true"/><!-- uri section --><uri name="/"/><uri name="/*.jsp"/><uri name="/*.jsv"/><uri name="/*.jsw"/><uri name="/servlet/*"/><uri name="/CpuLoad"/><uri name="/IOBound"/></webModule>

2 HTTP Response Code 500

A 500 indicates internal server error. The ODR encountered an error, and should be analyzed. If the problem can not be recreated, then collect the ODR logs present at the time the 500 occurred. The ffdc files would be particularly useful. If the problem can be recreated, collect the ODR must-gather.

Behavior1. The plug-in marks the ODR to be down if it detects an issue and does not forward the requests to ODR. This would result in an error code 500 so no logs will generated on the ODR side.

2. If an error code 500 is generated and logged in the local.log that means something is wrong on the ODR side.

8 4/22/2023

3. If an error code 500 is logged in the proxy.log, the problem is usually on the back end application server.

4. If the 500 logged in the local log, IBM would need the ODR must-gather along with the channel strings enabled on the ODR

Collect Diagnostic DataIf the problem cannot be recreated, then collect the ODR logs present at the time the 500 particular, the FFDC output should prove useful. If reproduce able, collect ODR must-gather.

3 HTTP Response Code: 503

Symptom

A 503 indicates that the service is unavailable. The request was mapped to an application, but there is no available application server to forward the request to.

Analyzing The following are some common things to look for, which may be seen in the ODR's target.xml: Are the applications available and started on the servers? Is the application server in maintenance mode? Is the application server reachable?Does the application server has a weight of 0?

Here is an example segment from target.xml.

            <server name="TestClusterA_dabtcNode03">                <property name="type" priority="1" value="APPLICATION_SERVER"/>                <property name="state" priority="1" value="STARTED"/>                <property name="reachable" priority="0" value="true"/>                <property name="weight" priority="1" value="20"/>                <property name="server.maintenancemode" priority="1" value="false"/>                <!-- serverApplication section -->                <serverApplication name="A">                    <property name="state" priority="1" value="STARTED"/>                </serverApplication>

If nothing jumps out, then ODR must-gather should be analyzed.

Note: odrDebug.py script which can be used to capture info regarding 503 problems

9 4/22/2023

4 when “slowness” is experienced

Step 1)

Invoke the odrPMIStats.py script.

Additional details about the script are included below.Step 2)Look at the PMI output of each active ODR. Look at the difference between average response time and average server response time. Note that these are averages of all requests coming in from the time PMI is enabled. Some tuning of the script on the fly may need to be done; it is recommended that customer understand what the script does and ways to tune it.

Condition # 1)

If (avg. RT - avg. SRT ) > 1 sec for a single WCM ODR

A. Take 3 thread dumps from the problematic ODRB. Take 3 netstat dumps from the machine hosting the problematic ODRC. Enable ODR must-gather for the single WCM ODRD. Capture 10 minutes of trace - will be important to get trace of a slow requestE. Disable traceF. Switch over to the hot standby WCM ODRsG. bounce the WCM ODR that was problematic & now out of production H. provide the trace, cores, netstat & pmi output to IBM

Condition # 2) If (avg. RT - avg. SRT ) > 1 sec for ALL WCM ODRs

I. Take 3 thread dumps of each ODRJ. Take 3 netstat dumps from each machine hosting the ODRsK. Enable ODR must-gather for all WCM ODRsL. Capture 10 minutes of trace - will be important to get trace of a slow requestM. Disable traceN. Switch over to running active + hot standby ODRs (ie all 4 WCM ODRs are to be activate

Condition # 3)

If adding additional WCM ODRs does not resolve the problemStep #1)Invoke the odrPMIStats.py script again to ensure the WCM ODR is adding in multiple seconds to the request flowStep #2)Perform a rolling restart of all WCM ODRsStep #3) provide the trace, cores, netstat & pmi output to IBM

5 Routing policy rule with IP operand, not working

Symptom

10 4/22/2023

A routing policy rule is in place which routes based on the client’s IP address. The expected routing is not occurring, making the rule to appear broken.Possible Cause If ODR can not receive request from the Web Server, you might needs to check your trusted secure proxy server configuration if your Web Server are not as trusted secure proxy server, configure them as a trusted secure proxy server.The configuration details can be found be accessing the below link. http://publib.boulder.ibm.com/infoccenter/wxdinfo/v6r1/index.jsp?topic=/com.ibm.websphere.ops.doc/info/odoe_task/tccgodrscen.html

6 Errors occur when attempt to start ODR from V6.0.2.x Admin Console

Symptom The ODR does not start from the administrative console for Websphere Extended Deployment Version 6.0.2.x when Firefox 2.0.x on SUSE Linux Enterprise Server (SLES) is used.CauseA request to start an ODR from the admin console times out due to a Firefox 2.0.x.

Resolving the problemStart the ODR from the command line.

7 Incorrect edition information displayed on application routing policy work class panel

Symptom When you have multiple application editions installed, such as A-edition1.0, A-edition2.0, A-edition3.0, and you configure the default action of the routing policy work class to A-edition1.0, the configuration details are correctly displayed from the Applications > All applications > application_name > Routing Policies > Work classes panel in the administrative console, When you uninstall A-edition1.0, the workclass.xml document in the configuration still defines A-edition1.0 as the default action.

Resolving the problemEnsure that you update any default actions or rule actions before you uninstall an application edition when you have multiple editions. If you do not have multiple editions, review your work class default actions and rule actions, and apply and save your changes directly in the console. For more information, see the Creating routing policies for application editions topic in the WebSphere Virtual Enterprise Information Center.

11 4/22/2023

8 Application placement controller shows -1 in the administrative console.

Symptom The application placement controller can become out of sync if you click Operational policies >Autonomic Managers >Application Placement Controller -> Runtime tab, and deselect the Enable field, which disables the application placement controller. When you save this change to the repository, the Runtime tab for the application placement controller displays the following text: "The placement controller cannot be reached. It appears to be disabled." If you make changes under the ‘runtime’ tab and then try to save them, then the display for ‘runtime’ may show -1 for all values.

Resolving the problem1. In the administrative console, click Operational policies >Autonomic Managers

>Application Placement Controller. Click the Configuration tab. 2. Select the Enable field. Edit the rest of the fields to have values other than -1.

Click OK. Click the Save to save the changes. 3. Click the Runtime tab. 4. Select the Enable field. Click OK.

After you complete these steps, the Runtime tab should display valid status.After you complete the steps to fix the condition, the application placement controller is enabled and synchronized with the configuration. the Runtime tab should not be used to save to the repository.

9 Dynamic Cluster creation fails with ARFM0173W

Symptom Creation of a WebSphere Extended Deployment Dynamic Cluster fails with the following messages being logged in the SystemOut.log file: WsmmTopologyR W ARFM0173W: Internal failure (cell=(cell_name), node=(node_name), toNotify=false). XDWsGroupMana I ODCF8010I: Peer layer setting up

CauseThe node listed in the ARFM0173W message might not have been augmented with the WebSphere Extended Deployment template.

Resolving the problemThe node listed in the ARFM0173W log entry needs to be augmented with a WebSphere Extended Deployment template.

10 Trusted Proxy Routing rules not work

12 4/22/2023

CauseForgot to Configure a Web Server as a Trusted Proxy

SymptomRewrite Rules do not work as expected Routing rules do not work as expected

Resolving the problemEnsure Trusted Proxy configured as trusted proxy

11 Application Server on Maintenance Mode 503

Cause

After performing the maintenance, forgot to bring it back on operation mode ordo not know servers or nodes are in Maintenance Mode

Symptom503 responses are returned

Unexpected system outages

Resolving the problemEnsure Application server are not on maintenance mode

12 Web Server Definitions could cause unexpected exceptions

CauseNo need to define Web Server definitions in DMGR administrative console at all.

SymptomWeb Server Definitions are not supported On Demand Router (ODR) is used to manage Web Servers Having an application mapped to a Web Server definition could cause unexpected exceptions

Resolving the problemDo not defined Web Servers definitions in Deployment Manger Admin Console.

13 4/22/2023

13 Mismatch of Installed products

CauseProducts at different maintenance levels

SymptomIf multiple products are installed on the same WAS at different maintenance levelsRequests will failServers will not start Unexpected exceptions will be thrown

Resolving the problemPlease ensure the environment is on latest version, fixpack across platform

14 Performance Monitoring Infrastructure (PMI) is enabled by default

CausePMI is enable by default

SymptomXD uses reports and visualization logs to monitor the state of the cell PMI is enabled by default on the back end servers to gather statistics and for health monitoring.

Resolving the problemTo disable PMI, the Memory Leak health policy needs to be disabled

15 High Availability Deployment Manger

CauseIncorrect use of the HA Dmgr

SymptomSupported Network File System (NFS) is not usedCIM is not configured when HA Dmgr is createdOnce HA Dmgr is created, wrong port is used to access HA DmgrNeed to follow a specific start up order for the Dmgr and ODR’s

14 4/22/2023

Resolving the problemNeed to follow a specific start up order for the Dmgr and ODR’sFirst Start DMGR Second NodeAgentThird ODRWeb Servers

16 Incorrect Centralized Installation Mangers (CIM) Configuration

CauseIncorrect configured of CIM

SymptomHow to use CIM without internet connection

SSH is used by default on Linux®/UNIX® platforms

Incompatibility between SSH protocols

Resolving the problemEnsure that CIM is configured properly

17 incorrect configuration of Core Croups

CauseIncorrectly configured Core GroupsToo many members in a core group

Multiple core groups not bridged together

Core Bridge automatic configuration not disabled

SymptomIf core groups are configured incorrectly; it can cause loss of service

Too many members in a core group

Multiple core groups not bridged together

Core Bridge automatic configuration not disabled

Core group performance tuning not done correctly

Resolving the problemEnsure Core Groups are configured properlyhttp://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/trun_ha_cfg_prefcoordinator.html

15 4/22/2023

18 Application Placement Controller (APC) can place servers in maintenance mode

CauseExcessive GC or OOM on node agents.The default behavior of APC can place your application in maintenance mode

SymptomAPC can place servers in maintenance mode

Max heap size on the nodeAgents is not increased

Resolving the problemEnsure APC is configured properly, for more information please visit the below linkhttp://publib.boulder.ibm.com/infocenter/wxdinfo/v6r1/index.jsp?topic=/com.ibm.websphere.ops.doc/info/reference/rodplacecustprop.html

6 ODR TracingIf a problem persists please follow the must-gather link to capture the tracing data according to the symptoms, IBM Support occasionally will modify the trace string so it a good to visit the below link.

MustGather: Read first for WebSphere Extended Deploymenthttp://www-01.ibm.com/support/docview.wss?rs=3023&uid=swg21224033

WebSphere Extended Deployment

http://www-01.ibm.com/support/search.wss?rs=3023&apar=include&q1=MustGatherDocument&tc=SSPPLQ&loc=en_US&cs=utf-8&lang=en&sort=rk&p=3

manageODC.py scriptThe manageODC.py script manages the ODC tree. The ODC tree is an in-memory representation of the state of a WebSphere Application Server cell.

Purpose

The manageODC.py script can add and remove nodes and edges, or modify the value of properties on a node. You can also use the script when troubleshooting routing policy errors for the on demand router

16 4/22/2023

Location

The manageODC.py script is located in the install_root/bin directory.

UsageThe script usage for general help follows:

./wsadmin.sh|bat -lang jython -f manageODC.pyThe script usage for operation-specific help follows:./wsadmin.sh|bat -lang jython -f manageODC.py operation –helpGenerate a target.xml file to determine the ODC names to plug into the script

There are three ways to generate target. xml file

Use the odrDebug.py or dumpOdrState.jacl If experiencing 404 or 503 then target.xml will be dumped in the systemout.log If ODC is enabled then a target.xml is generated when the ODR is restarted or if

there any configuration changes.

Operation

You can perform the following operations with the manageODC.py script:manageODC.py can be found under $WAS_HOME/bin

Operation: *removeODCNode * Removes a node. Parameters

odcNodePath Specifies the full ODC tree path of the node to remove. nodeName Specifies the name of the Websphere node containing the server that

initiates the removal. serverName Specifies the name of the server to initiate the removal.

Operation: addODCNode Creates a new node. Parameters:

odcParentNodePath Specifies the full ODC tree path for the parent of the new node to be created.

odcNodeType Specifies the ODC node type of the new node to be created. newNodeName Specifies the name of the new node to be created. nodeName Specifies the name of the Websphere node containing the server that

initiates the addition. serverName Specifies the name of the server to initiate the addition. [--p odcPropertyDescriptor priority::value] Specifies the name of the ODC

property to be modified on the new node priority. Value is the priority and value to set the ODC property to on the new node. Priority can be omitted if the default value is used.

17 4/22/2023

[--l linkOdcNodePath] Specifies the full ODC tree path of the node for which an edge is to be created

and similar formatting for the rest. removeODCEdge Removes the link between two nodes. odcNodePathA odcNodePathB Specifies the full ODC tree paths of the nodes to be unlinked. nodeName Specifies the name of the Websphere node containing the server that initiates the removal. serverName Specifies the name of the server to initiate the removal. addODCEdge Links one node to another node. odcNodePathA odcNodePathB Specifies the full ODC tree paths of the nodes to be linked. nodeName Specifies the name of the Websphere node containing the server that initiates the addition. serverName Specifies the name of the server to initiate the addition. *modifyODCProperty * Modifies a specified ODC property of a node. odcNodePath Specifies the full ODC tree path of the node whose property is to be modified. odcPropertyDescriptor Specifies the name of the ODC property to be modified. priority::value Specifies the priority and value to set the ODC property to. Priority can be omitted if the default value is used. nodeName Specifies the name of the Websphere node containing the server that initiates the modification. serverName Specifies the name of the server to initiate the modification.

Generate target.xmlGenerate a target.xml file to determine the ODC names to include in the script. The following code example shows a shortened version of a target.xml file, where parameters for the cell, node, and server that you want to use in the script are located.

Command to generate target.xml./wsadmin.sh -lang jython -f odrDebug.py setHttpDebug my_node my_ODR 503 true 2

(the above command will generate a full target.xml in the ODR’s SystemOut.log when you hit a 503 routing failure

through that ODR)

<cellGroup name="target"> <!-- cell section --> <cell name="Cell1"> <!-- node section --> <node name="metis07"> <!-- server section --> <server name="odr">

<property name="state" priority="1" value="STOPPED" />

18 4/22/2023

To delete server odr from the ODC tree, type the following command:./wsadmin.sh -lang jython -f manageODC.py removeODCNode /cell/Cell1/node/metis07/server/odr <myNode> <myServer>

Note that /cellGroup/target is never specified as part of the path.

In this example, The property ODC object is state, with a value of STOPPED, and a priority of 1.

To change the property to STARTED, use the following command: ./wsadmin.sh -lang jython -f manageODC.py modifyODCProperty /cell/Cell1/node/metis07/server/odr state 1::STARTED <mynode> <myserver>

To change weight value./wsadmin.sh -lang jython -f manageODC.py modifyODCProperty /cell/XDPRODUCTION/node/<server_nodename>/server/<servername> weight 1::2 <server_node> <servername>To set up on Debug mode./wsadmin.sh -lang jython -f odrDebug.py setHttpDebug my_node my_ODR 503 true 1

(replacing my_node and my_ODR with real values)

To Generate target.xml

./wsadmin.sh -lang jython -f odrDebug.py setHttpDebug my_node my_ODR 503 true 2

(the above command will generate a full target.xml in the ODR’s SystemOut.log when you hit a 503 routing failure

through that ODR)

Another way to Generate target.xml

set MBean [$AdminControl queryNames *:*,type=TargetTreeMbean,process=<processName>]set Results [$AdminControl invoke $MBean getTargetTree]puts $Results

7 Bypass ODR (This feature is ONLY available on 6.1.0.5)If an ODR is suspected to be a problem you can configure your JVM to bypass the ODR. Define a new custom property to configure the Web server plug-in configuration to route requests directly from the Web server to a back-end application server. You can configure certain requests to route through an on demand router (ODR) and configure other requests to route directly to a back-end application server. Typically, an ODR acts as a gateway through which requests sent by a Web server flow to a back-end application server. You can define the ODR_Module_Routing_Policy custom property for the plugin-cfg.xml file to redirect specific requests that you do not want to route through the ODR. Instead, the requests are routed directly from the Web server to the back-end server. Alternatively, you can reset the custom property so that the ODR resumes intercepting requests. The format of the custom property value is a comma-separated list of module paths, such as cell/appName/edition/moduleName=value.

19 4/22/2023

Procedure

In the administrative console, click System administration > Cell > Custom Properties > New. Type ODR_Module_Routing_Policy as the name of the custom property.Type the value of the custom property. Set the value to cell/appName/edition/moduleName=direct to route requests directly to the

back-end server.Set the value to cell/appName/edition/moduleName=ODR to route requests through the ODR

before the back-end server receives the requests.For example, if you set the value to

cell/app/edition/module=direct,cell/app2/edition/module=ODR,

each module is configured independently as to whether requests for that module are sent through the ODR or directly to the back-end server. You can use a wildcard (*) in place of the appName, edition, and moduleName variables.Click Apply and save your changes.

Example In the following example, the custom property is set to route requests to a back-end application server. A wildcard is used in place of the appName, edition, and moduleName variables.myCell/*/*/*=direct

Manual process to bypass ODRStep1. Generate plug-in from the Network Deployment ManagerNOT from the On Demand Router (ODR)Step2. Ensure ports are open between Web Server and Application ServerStep3. Ensure SSL files are copied to Web Servers, if required Step4. Propagate newly generated plugin-cfg.xml file on Web Servers Step5. Restart the Web ServersStep6. Enable plug-in tracing in httpd.conf fileStep7. Perform the validation of your application. Step8. If everything’s working as expected, disable the plug-in trace in httpd.conf file

8 ODR Resources IBM Information Centerhttp://publib.boulder.ibm.com/infocenter/wxdinfo/v6r1/index.jsp?topic=/com.ibm.websphere.ops.doc/info/welcome_61_ooxd.htmlWebSphere Extended Deployment Support

20 4/22/2023

http://www-01.ibm.com/software/webservers/appserv/extend/support/Recommended fixes for WebSphere Extended Deploymenthttp://www-01.ibm.com/support/docview.wss?rs=3023&uid=swg27005709Developer Workshttp://www.ibm.com/developerworks/wikis/display/xdoo/HomeIf problem persistence, please open a PMR by accessing the below link or call 1-800-IBM-SERVhttp://www-01.ibm.com/software/support/probsub.html

21 4/22/2023