TroubleShooting: Object Request Broker (ORB) problems

Problems with Multiple ORBs

It is not recommended to have multiple ORBs within a client or server JVM. WLM client functionality in particular can be adversely affected when multiple ORBs exist within a client JVM. Servers using static ports will also experience failures when trying to init multiple ORBs. This policy is documented here:
Object Request Brokers
Client-side programming tips for the Object Request Broker service

When application code (client or server) needs a reference to the ORB, the JNDI approach should be used for obtaining that reference via the InitialContext object. See the following:
Initial context support
Developing applications that use JNDI
Example: Getting an initial context by setting the provider URL property
Example: Getting an initial context with CosNaming
Troubleshooting WLM issues in WebSphere Application Server (Question 6)

If you find a JVM is init'ing more than 1 ORB, use the call stacks to determine the code from which the additional ORBs are init'ed and correct the code as recommended above.

How to determine if a JVM has multiple ORBs:
1. Using a javacore or thread dump, look for Reader or Listener Thread names:

"RT=383:P=570960:O=123:WSSSLTransportConnection[addr=XXX.XXX.XXX,port=47765,local=46289]" "LT=496:P=570960:O=123:port=46288"

The O= # is the ORB instance id.
If there are any numbers greater than 0, then there are multiple ORBs.
2. When ORB trace is turned on, a call stack will be outputted each time a new ORB is instantiated. Using ORB trace (preferably from startup), look for the following trace phrase: "ORB.init call sequence"

Server ORB.init call stack example:

[3/16/17 15:44:43:800 EDT] 00000001 ORBRas 1 com.ibm.rmi.corba.ORB parseProperties:2108 P=483745:O=0:CT ORB.init call sequence: com.ibm.wsspi.bootstrap.WSPreLauncher.main(WSPreLauncher.java:165) com.ibm.wsspi.bootstrap.WSPreLauncher.launchEclipse(WSPreLauncher.java:402) org.eclipse.core.launcher.Main.run(Main.java:981) org.eclipse.core.launcher.Main.basicRun(Main.java:282) ... com.ibm.ws.runtime.WsServer.main(WsServer.java:59) com.ibm.ws.runtime.WsServerImpl.main(WsServerImpl.java:697) com.ibm.ws.runtime.WsServerImpl.start(WsServerImpl.java:224) com.ibm.ws.runtime.WsServerImpl.bootServerContainer(WsServerImpl.java:311) com.ibm.ws.runtime.component.ServerImpl.start(ServerImpl.java:540) com.ibm.ws.runtime.component.ContainerImpl.start(ContainerImpl.java:618) com.ibm.ws.runtime.component.ContainerImpl.startComponents(ContainerImpl.java:627) com.ibm.ws.runtime.component.ContainerHelper.startComponents(ContainerHelper.java:540) com.ibm.ws.runtime.component.ORBImpl.start(ORBImpl.java:482) com.ibm.ejs.oa.EJSORB.init(EJSORB.java:55) com.ibm.ejs.oa.EJSServerORBImpl.<init>(EJSServerORBImpl.java:102) com.ibm.ejs.oa.EJSORBImpl.initializeORB(EJSORBImpl.java:179) com.ibm.ws.orb.GlobalORBFactory.init(GlobalORBFactory.java:92) org.omg.CORBA.ORB.init(ORB.java:380)

Client ORB.init call stack example:

org.omg.CORBA.ORB.init(ORB.java:368) from com.ibm.ws.orb.GlobalORBFactory.init(GlobalORBFactory.java:85) from com.ibm.ejs.oa.EJSORBImpl.initializeORB(EJSORBImpl.java:174) from com.ibm.ejs.oa.EJSClientORBImpl.<init>(EJSClientORBImpl.java:97) from com.ibm.ejs.oa.EJSClientORBImpl.<init>(EJSClientORBImpl.java:73) from com.ibm.ejs.oa.EJSORB.init(EJSORB.java:386) from com.ibm.ws.naming.util.Helpers.getOrb(Helpers.java:305) from com.ibm.ws.naming.util.WsnInitCtxFactory.getInitialContextInternal(WsnInitCtxFactory.java:383) from com.ibm.ws.naming.util.WsnInitCtx.getContext(WsnInitCtx.java:113) from com.ibm.ws.naming.util.WsnInitCtx.getContextIfNull(WsnInitCtx.java:428) from com.ibm.ws.naming.util.WsnInitCtx.lookup(WsnInitCtx.java:144) from javax.naming.InitialContext.lookup(InitialContext.java:361) from MyTest2.main(MyTest2.java:48)

 

Failures Due to Duplicate Cell Names

Workload Manager (WLM) clients can experience unexpected errors when cross-cell communication occurs between cells whose cell names are not unique. These failures can include javax.naming.NameNotFoundException or misrouted requests. WLM routing information is organized by CellName/ClusterName/MemberName. If the client is routing to multiple cells with the same name, WLM has no way to distinguish those duplicate-named cells.

The following KnowledgeCenter links document the requirement for unique cell names:

manageprofiles command
Creating cell profiles

Cell names must be unique when:

· The product is running on the same physical machine or cluster of machines, such as a sysplex.
· The network connectivity between entities is required either between the cells or from a client that must communicate with each of the cells.
· The namespaces are federated.

Solution:
· WAS v9 – use the renameCell command
Utility command group of the AdminTask object (renameCell)
· WAS v8.5.5 and previous - reinstall or create new profile(s)