PQ61949: MULT-THREADED JAVA CLIENT ON SOL (OR AIX OR LINNUX) TALKING TO AIX CLONES WLM WORKS UNTIL WSCP OR CONSOLE IS USED TO STOP CLONE


APAR

APAR status
Closed as program error.

Error description
This problem has now been isolated to WLM failover. If we
run the mult-threaded java  client on Solaris (or AIX or Linnux)
talking to the two AIX  clones, WLM works until we use wscp (or
Adminconsole) to stop a clone then we get in a state where com
failures are received at the client. Even if we start a 'new'
client we receive the comm error. Looks like LSD is attempting
to talk to the clone (which is no longer there) on the old
port.  (This situation arises when we are doing failover
testing.)
Local fix
NA
Problem summary
****************************************************************
* USERS AFFECTED: All clients of WebSphere Application Server  *
*                 applications which make use of the WLM       *
*                 (Workload Management) feature.               *
****************************************************************
* PROBLEM DESCRIPTION: When running WAS 3.5.5, a JNDI lookup   *
*                      might result in an                      *
*                      org.omg.CORBA.COMM_FAILURE even though  *
*                      WLM is being used and at least one      *
*                      clone is running.  This problem does    *
*                      not occur in any PTF prior to or        *
*                      subsequent to PTF 5.                    *
****************************************************************
* RECOMMENDATION:                                              *
****************************************************************
The problem was created when up-level code which provides the
ability to access WebSphere 4.0 name servers was back-ported
to WAS 3.5.5.  The back-ported code also contains additional
function to allow access to non-WebSphere CosNaming name
servers.  It turns out that this additional function is not
compatible with WLM.

Note that the incompatibilty with WLM does not exist on 4.0.
Problem conclusion
Since the problem only exists on 3.5.5, only an e-fix was
necessary.  The fix is already in the code base for versions
3.5.6 and higher.

After the e-fix is applied, the feature which provides
interoperability with non-WebSphere name servers is by
default disabled.  It can be enabled by passing the
following property setting to the InitialContext
constructor:

   com.ibm.websphere.naming.jndi.interoperability=full

The default value for this property is "partial".  Note that
full interoperability cannot be used in installations which
exploit WLM.

The following constants have been defined in the constants
class com.ibm.websphere.naming.PROPS for this property
name and the valid values for it:constructor:com.ibm.websphere.naming.jndi.interoperability=fullThe default value for this property is "partial".  Note thatfull interoperability cannot be used in installations whichexploit WLM.The following constants have been defined in the constantsclass com.ibm.websphere.naming.PROPS for this property
PROPS.JNDI_INTEROP (property name) PROPS.JNDI_INTEROP_FULL (property value) PROPS.JNDI_INTEROP_PARTIAL (property value) The ability to access up-level WebSphere name servers is not affected by this property setting. Also, the conflict between full interoperability and WLM does not exist in WebSphere versions 4.0 and higher.
name and the valid values for it:PROPS.JNDI_INTEROP (property name)PROPS.JNDI_INTEROP_FULL (property value)PROPS.JNDI_INTEROP_PARTIAL (property value)The ability to access up-level WebSphere name servers is notaffected by this property setting. Also, the conflictbetween full interoperability and WLM does not exist inWebSphere versions 4.0 and higher.
Temporary fix
Comments
APAR information
APAR numberPQ61949
Reported component nameWAS ADVANCED AI
Reported component ID5648C8400
Reported release350
StatusCLOSED PER
PENoPE
HIPERNoHIPER
Submitted date2002-06-05
Closed date2002-06-26
Last modified date2002-06-26

APAR is sysrouted FROM one or more of the following:

APAR is sysrouted TO one or more of the following:APAR is sysrouted FROM one or more of the following:


Modules/Macros
NAMING
APAR is sysrouted TO one or more of the following:Modules/Macros

Fix information
Fixed component nameWAS ADVANCED AI
Fixed component ID5648C8400

Applicable component levels
R350 PSYUP











Document Information

Product categories: Software, Application Servers, Distributed Application & Web Servers, WebSphere Application Server, General
Software version: 350
Reference #: PQ61949
IBM Group: Software Group
Modified date: 2002-06-26