IBM Support

The status of the server displays incorrectly in the workbench

Technote (troubleshooting)


This document applies only to the following language version(s):

English

Problem(Abstract)

After creating a server or while starting the server, the workbench may not reflect the correct state of the server. The following are examples of the problem scenarios:


  • The server is started, but in the Servers View the status of the server displays as Stopped.

  • When attempting to start a server, the console view displays the server as successfully started by displaying the message, "Server <serverName> open for e-business". However, the status of the server in the Server View remains in a 'starting' state.

Cause

The workbench has problems establishing a connection to the server.

Resolving the problem

There are many reasons the workbench might not be able to connect to a started server, below is a list of troubleshooting tips:

Incorrect ports
The workbench uses either Remote Method Invocation (RMI) or SOAP to establish a connection to the server. Each server profile has port values defined for each of these protocols. The values of the ports in the workbench must match those of the server.

To view the value of the port specified on the server, start the Administrative Console. In the Administrative Console, select Servers > Application Servers >serverName >Ports. Record the port values of the BOOTSTRAP_ADDRESS (RMI) and SOAP_CONNECTOR_ADDRESS (SOAP) to verify if they match those in the workbench.

For information on how to access the Administrative Console see the following article:

http://www-01.ibm.com/support/knowledgecenter/SSZLC2_7.0.0/com.ibm.commerce.install.doc/tasks/tig_start_was_admin_console.htm?lang=en

To view the value of these ports specified in the workbench, double-click on the server in the Servers View to open the server editor. In the server editor, verify the port values under the Server section match those of the server. If not, correct the port values specified in the workbench and try your connection again.

Firewall
If there is a firewall between the development machine and the server, verify that you are using the SOAP connection type for the server. In addition, verify the firewall allows connections through the configured SOAP connector port. The SOAP connectors are designed to be more tolerant to the firewall.

Invalid security settings
If the server security is enabled, the correct security credentials must be provided. Open the server editor by double-clicking on the server in the Servers View and expand the Security section. Verify the Security is enabled on this server check box is selected, and a valid user ID and password for the secure server are provided. A valid user ID and password is one that can authenticate against the server security registry, for example, credentials that can be used as a login to the Administrative Console.

Invalid runtime used in the workbench to define the server
When defining a server in the workbench, you must specify a runtime for the target server. The server runtime environment defined in the workbench must match the target server and its version-level.

To verify the version level of the target server, view the Welcome page of the Administrative Console.

To verify the server runtime of the server in the workbench, open the server editor and verify the runtime specified in the Runtime field under the General section matches the version level of the server. If it does not, correct the server runtime used in the workbench server to match that of the target server.

Local server IP address changed
If the server is running on the same machine as the workbench, when the IP address of the machine changes the workbench may have difficulty reconnecting to the server. This scenario occurs most often in a wireless network environment where the IP address of the machine may change when moving from a local area network (LAN) to a wireless adapter. The details and workarounds for this issue are referenced in the following Technote:


SOAP connector runs out of Operating System network resources
There is a known issue that can cause the SOAP connector to continuously consume Operating System network resources over a long period of time. Eventually this can exhaust the Operating System network resources, and as a result the workbench is unable to establish further connections. In addition to the information mentioned in the technote below, the following output may be displayed multiple times on the console for the IBM® WebSphere® Application Server when this problem occurs:

08/11/07 10:49:37:343 EST] 000000f6 HttpConnectio E Unable to read and handle request: null
08/11/07 10:49:37:343 EST] 000000f6 HttpConnectio E Unable to read and handle request: null
[08/11/07 10:49:41:296 EST] 000000eb HttpConnectio E Unable to read and handle request: null

The details and workarounds for this issue are referenced in the following Technote:
http://www.ibm.com/support/docview.wss?uid=swg1PK38909

If the information above does not help to resolve the issue please contact IBM Support for further assistance using the Service Request (SR) tool: ( http://www.ibm.com/software/support/probsub.html)

You may also visit the WebSphere Application Server Support Web site: http://www.ibm.com/software/webservers/appserv/was/support/, contact 1-800-IBM-SERV (U.S. only) or consult the Software Support Handbook:

http://www14.software.ibm.com/webapp/set2/sas/f/handbook/contacts.html

Mismatched Security Algorithm Settings
If the SSL certificate of WebSphere Application Server does not meet the more stringent security requirements of newer Java(tm) virtual machines (JVMs), then the communication to WebSphere Application Server fails. For example, the server status might show as stopped even though it is started.

The problem occurs when Rational Application Developer is using Oracle Java runtime environment (JRE) version 7 update 40 or newer, or an IBM(r) Runtime Environment for Java 1.7 SR6 or newer. In these versions of JREs, the use of an x.509 certificate with RSA keys of less than 1024 bits in length is disallowed. This new behavior is the result of adding a key size requirement in these JREs in the jre/lib/security/java.security file as follows:

jdk.certpath.disabledAlgorithms=MD2, RSA keySize < 1024

This means that any certificate signed with the MD2 message digest algorithm or with a Rivest Shamir Adleman (RSA) key of length less than 1024 bits, is not acceptable. By default, the key size for certificates in WebSphere Application Server V7 is 1024 whereas for WebSphere Application Server V8.x it is 2048. If the customer creates a profile with a key size smaller than the default, the workbench fails to communicate with WebSphere Application Server and the server status is not detected correctly. This situation occurs because the newer values (key size less than 1024) do not adhere to the requirements of the key size for Oracle JRE version 7 update 40 or newer, or an IBM Runtime Environment for Java 1.7 SR6 or newer. Therefore, use the default values only when a new profile is created.

Related information

Local server IP address changed

Cross reference information
Segment Product Component Platform Version Edition
Software Development Rational Application Developer for WebSphere Software Server Tooling Windows, Linux 7.0 All Editions

Product Alias/Synonym

RAD
RSA
WID
AST

Document information

More support for: WebSphere Application Server
Application Server Toolkit (AST)

Software version: 6.0, 6.1, 6.1.1, 7.0

Operating system(s): Linux, Windows

Reference #: 1266028

Modified date: 17 June 2014


Translate this page: