Fix (APAR): PK46749 Status: Fix Release: 6.1.0.7,6.1.0.5,6.1.0.3 Operating System: AIX,HP-UX,Linux,Linux pSeries,Linux Red Hat - pSeries,Solaris,Windows Supersedes Fixes: CMVC Defect: Byte size of APAR: 39866 Date: 2007-08-27 Abstract: Attempting to start listener ports configured under the message listener service results in a Java Virtual Machine (JVM) crash. Description/symptom of problem: PK46749 resolves the following problem: ERROR DESCRIPTION: When using WebSphere Application Server v6.1 64-bit with WebSphere MQ 6.0.2 64-bit, the application server JVM crashes on startup. The problem occurs when the runtime attempts to start listener ports configured under the message listener service. The listener ports are configured to use connection factories which use a transport type of "BINDINGS". The problem does not occur with a transport type of "CLIENT". The application server's SystemOut.log file will report a line similar to the following as the last line in the file prior to the crash: [5/14/07 13:43:10:715 EDT] 0000001f MDBListenerIm I WMSG0042I: MDB Listener myListenerPort started successfully for JMSDestination jms/MY.DESTINATION.Q The native_stdout.log might also report this when the system runs on Solaris: Java HotSpot(TM) 64-Bit Server VM warning: Unexpected Signal 10 occured under user-defined signal handler 0xfffffffed005f290 # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGBUS (0xa) at pc=0xffffffff7e292f78, pid=19577, tid=83 # # Java VM: Java HotSpot(TM) 64-Bit Server VM (1.5.0_10-b02 mixed mode) # Problematic frame: # V [libjvm.so+0x292f78] # # An error report file with more information is saved as hs_err_pid19577.log LOCAL FIX: Change the transport type of the connection factory to "CLIENT" instead of "BINDINGS". As the WAS JVM is crashing upon startup, it may not be possible to access the admin console to change the transport setting on the connection factory. If this is the case, find the TCF in the appropriate resources.xml file in the WAS profile "config" directory (either from the cell, node or server directories). Change the transportType="BINDINGS" to transportType="CLIENT". The application server should then start, and allow the admin console to be used to configure the rest of the connection factory properties. If this is a network deployment environment, the dmgr should be able to start successfully to allow the configuration changes for the resources. PROBLEM SUMMARY USERS AFFECTED: Users of IBM WebSphere Application Server at versions 6.1 through 6.1.0.10, inclusive, 64 bit, and using IBM WebSphere MQ Series at version v6.0.2.0, 64 bit, and with transport type "BINDINGS" (but not with transport type "CLIENT"). PROBLEM DESCRIPTION: Attempting to start listener ports configured under the message listener service results in a Java Virtual Machine (JVM) crash. RECOMMENDATION: None The problem occurs when the runtime attempts to start listener ports configured under the message listener service. The listener ports are configured to use connection factories which use a transport type of "BINDINGS". The problem does not occur with a transport type of "CLIENT". The application server's SystemOut.log file will report a line similar to the following as the last line in the file prior to the crash: [5/14/07 13:43:10:715 EDT] 0000001f MDBListenerIm I WMSG0042I: MDB Listener myListenerPort started successfully for JMSDestination jms/MY.DESTINATION.Q The native_stdout.log might also report this when the system runs on Solaris: Java HotSpot(TM) 64-Bit Server VM warning: Unexpected Signal 10 occured under user-defined signal handler 0xfffffffed005f290 # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGBUS (0xa) at pc=0xffffffff7e292f78, pid=19577, tid=83 # # Java VM: Java HotSpot(TM) 64-Bit Server VM (1.5.0_10-b02 mixed mode) # Problematic frame: # V [libjvm.so+0x292f78] # # An error report file with more information is saved as hs_err_pid19577.log PROBLEM CONCLUSION: This problem was fixed by patching files in the Application Server image with class from the Equinox feature 125045. The classes were patched in the Application server server pack version 6.1.0.11. Please refer to the recommended updates page for delivery information: http://www.ibm.com/support/docview.wss?rs=180&uid=swg27004980 For information on the Equinox feature 124054, see the Eclipse bugzilla defect: https://bugs.eclipse.org/bugs/show_bug.cgi?id=125045 The change means that JNI libraries are not copied into the OSGi bundle, but instead are loaded from the default MQ location. Note that the feature impacts classes that exist in three locations in the Application Server image, but that only one copy of the classes were updated. The classes exist in these three locations: AppServer\plugins\ org.eclipse.osgi_3.2.1.R32x_v20060919.jar AppServer\deploytool\itp\plugins\ org.eclipse.osgi_3.2.1.R32x_v20060919.jar AppServer\bin\ProfileManagement\plugins\ org.eclipse.osgi_3.2.1.R32x_v20060919.jar Only the first of these locations (under the Application Server "plugins" directory) was patched. Directions to apply fix: Fix applies to Editions: Release 6.1 _X_ Application Server (Express or BASE) _X_ Network Deployment (ND) Install Fix to: Method: _X_ Application Server Nodes _X_ Deployment Manager Nodes _X_ Both NOTE: The user must: * Have Administrative rights in Windows, or be the Actual Root User in a UNIX environments. * Logged in with the same authority level when unpacking a fix, fix pack or refresh pack. * Be at V6.0.2.2 or newer of the Update Installer. This can be checked by reviewing the level of the Update Installer in file /updateinstaller/version.txt. The Update Installer can be downloaded from the following link: http://www.ibm.com/support/docview.wss?rs=180&uid=swg21205991 For detailed instructions to Extract the Update Installer see the following Technote: http://www-1.ibm.com/support/docview.wss?rs=180&uid=swg21205400 1) Copy 6.1.0.3-WS-WAS-IFPK46749.pak file directly to the maintenance directory 2) Shutdown WebSphere Manually execute setupCmdLine.bat in Windows or . ./setupCmdLine.sh in Unix from the WebSphere instance that maintenance is being applied to. 3) Launch Update Installer 4) Enter the installation location of the WebSphere product you want to update. 5) Select the "Install maintenance package" operation. 6) Enter the file name of the maintenance package to install (6.1.0.3-WS-WAS-IFPK46749.pak file which was copied in the maintenance directory). 7) Install the maintenance package. 8) Restart WebSphere Directions to remove fix: NOTE: * The user must have Administrative rights in Windows, or be the Actual Root User in a UNIX environments. * FIXES MUST BE REMOVED IN THE ORDER THEY WERE APPLIED * DO NOT REMOVE A FIX UNLESS ALL FIXES APPLIED AFTER IT HAVE FIRST BEEN REMOVED * YOU MAY REAPPLY ANY REMOVED FIX Example: If your system has fix1, fix2, and fix3 applied in that order and fix2 is to be removed, fix3 must be removed first, fix2 removed, and fix3 re-applied. 1) Shutdown WebSphere Manually execute setupCmdLine.bat in Windows or . ./setupCmdLine.sh in Unix from the WebSphere instance that uninstall is being run against. 2) Start Update Installer 3) Enter the installation location of the WebSphere product you want to remove the fix. 4) Select "Uninstall maintenance package" operation. 5) Enter the file name of the maintenance package to uninstall (6.1.0.3-WS-WAS-IFPK46749.pak). 6) UnInstall maintenance package. 7) Restart WebSphere Directions to re-apply fix: 1) Shutdown WebSphere. 2) Follow the Fix instructions to apply the fix. 3) Restart WebSphere. Additional Information: