Web services client runtime troubleshooting tips
Use these tips to troubleshoot web services clients.
Each section in this topic is a problem that you might experience during the run time of a web services client. A solution is provided to help you troubleshoot the problem.
Use the ASYNC_TIMEOUT_MILLISECONDS property to avoid receiving a time out exception for JAX-WS synchronous clients
org.apache.axis2.AxisFault:
Time out while waiting for the server to send the response
,
set the asynchronous timeout property, com.ibm.websphere.webservices.jaxws.Constants.ASYNC_TIMEOUT_MILLISECONDS
,
on the client to control the amount of time to wait for the response
from the server before a time out error message is generated. Specify
the timeout property in milliseconds to set the amount of time to
wait for a reply to an asynchronous request. The following example
demonstrates how to set this property: ((BindingProvider) port).getRequestContext().put(com.ibm.websphere.webservices.jaxws.Constants.ASYNC_TIMEOUT_MILLISECONDS, 30000);
The connection to the remote host fails
WSWS3713E: Connection to the remote host host_name failed
,
displays when you are trying to connect to the remote host, check
the following items:- If the host name that is listed in the error message is the correct host name, you need to verify that the application with the web service is running and is available.
- If the host name that is listed in the error message is the incorrect host name, you might need to update the WSDL file for the web service or override the endpoint URL that the host name needs to use. To override the web service endpoint URL, see the configuring web services client bindings information to learn how to configure the port information.
Running your web service client with an ibm-jaxrpc-client.jar file in a Solaris environment can cause an exception
java -jar <java_application>.jar
,
to specify a Java application in a Solaris environment,
a class not found exception can occur. To avoid an exception, use
the -classpath option instead of the -jar option,
for example, java -jar <your_client_application>.jar, <main_class_file>
The problem occurs because the Sun JDK classloading specification is more strict than the IBM® JDK specifications.
- Use the -classpath option instead of the -jar option,
for example,
java -jar <java_application>.jar, <main_class_file >
- Use the -Djava.ext.dirs option with the -jar option,
for example,
export WAS_HOME=/opt/IBM/WebSphere/AppServer ${WAS_HOME}/java/jre/bin/java -Djava.ext.dirs=${WAS_HOME}/runtimes -jar <your_client_application>.jar, <your_client_application>.args
- Modify Class Path in Manifest.MF to include the Java archive
(JAR) files that you need, for example,
Class Path: /opt/IBM/WebSphere/AppServer/runtimes/ibm-jaxrpc-client.jar
Resolving DNS causes performance problems when using HTTP to connect to a service endpoint interface that is not based on a private IP address
The DNS service is often not available when you use HTTP to connect to a service endpoint interface that is based on a private IP address. Therefore, performance is degraded during the DNS resolution.
This problem occurs when the outbound HTTP connector in the web service engine attempts to resolve the host address name and times out.
You can modify the HOSTS file for the targeted IP address to avoid the DNS resolution.
Runtime migration error
WSWS3701E: Error: An exception was encountered. Use wsdeploy to deploy your application.
This might correct the problem. The exception is <exception data>.
This exception indicates that a problem occurred while running the application that was developed with tools supported by versions prior to Version 6. A solution to the problem is to uninstall the application, run the wsdeploy command and redeploy the application.
The wsdeploy command is supported by Java API for XML-based RPC (JAX-RPC) applications. The Java API for XML-Based Web Services (JAX-WS) programming model that is implemented by the application server does not support the wsdeploy command. If your web services application contains only JAX-WS endpoints, you do not need to run the wsdeploy command, as this command is used to process only JAX-RPC endpoints.
WebServicesFault exception displays during the application server run time for certain Web Services Description Language (WSDL) files
A WebServicesFault
exception
displays during the application server run time for WSDL files that
define operations with document style
and literal
use
and use the SOAP header to transmit the input data.
If
the WSDL files define the operation with document style
and literal
use
and this operation maps the input to the SOAP header,
the web services run time fails to find the correct operation for
the target service and the WebServicesFault
exception
displays.
To solve the problem, change the WSDL files so that the operation does not have input that uses the SOAP header to transmit the data.
Increase the value of the ConnectionIOTimeOut parameter to avoid receiving an exception when hosting web services
When
hosting web services on WebSphere Application Server,
the following exception displays: java.net.SocketTimeOutException:
Read Timed Out
.
A slow network connection between the client and the web service causes this problem. In such cases, the HTTP socket might time out before the web service engine completely reads the SOAP request. In the majority of cases, a sudden increase in overall network activity causes this problem. The problem can also occur when the client is accessing the web service from a slow network connection and when the SOAP request has a lot of data.
- Name: ConnectionIOTimeOut
- Value: 30
Increase the value of the syncTimeout parameter to avoid receiving an exception when hosting web services clients
You
can also get the java.net.SocketTimeOutException: Read Timed
Out
error when the syncTimeout parameter that is used by
the web services client is not set correctly. This is important to
know because if you set the ConnectionIOTimeout parameter to zero
with the expectation that a timeout is preventable as stated in the
topic HTTP transport custom properties
only the connection
timeout is prevented. The only way to make sure that a request from
an HTTP client, which can be a Web services client, does not time
out, is to increase the syncTimeout parameter setting.
The syncTimeout parameter is only used by the web services client. This parameter can be set in the web services stub that is a timeout for the web services call.
To solve the problem, increase the syncTimeout parameter for the web services client. To learn how to set this parameter, see the configuring the JAX-RPC web services client bindings in the ibm-webservicesclient-bnd.xmi deployment descriptor information.
Executing a web services client application with session persistence turned on or in a clustered environment might cause a WebServicesFault error
[mm/dd/yy hh:mm:ss:ttt EST] 0000006e SystemErr R WebServicesFault
faultCode: {http://schemas.xmlsoap.org/soap/envelope/}Server.generalException
faultString: java.io.IOException: Connection close: Read failed.Possible end of
stream encountered.
faultActor: null
faultDetail:
You can avoid this error by following one of two ways:- Set the com.ibm.websphere.webservices.http.requestResendEnabled
property to true, for example, com.ibm.websphere.webservices.http.requestResendEnabled=true.
When this property is set to true, the web
services client is programmed to re-send the request if the request
has failed. Monitor your client runtime if you change the property
value, because the request might be sent twice.
For example, if your client is a banking application, and you set the com.ibm.websphere.webservices.http.requestResendEnabled property to true, a transaction might be posted twice to an account. See the configuring additional HTTP transport properties using the JVM custom property panel in the administrative console information to learn how to configure the com.ibm.websphere.webservices.http.requestResendEnabled property.
- If you are using the IBM HTTP
Server on an AIX® or Linux® operating
systems, you can set the MaxSpareThreads property to the same value
as the MaxClients property that is located in the httpd.conf file.
For example, if the MaxClients=600, change the MaxSpareThreads to
equal 600 (MaxSpareThreads=600).
The advantage to choosing this way to avoid the error, is that the IBM HTTP Server does not shut down idle or near-idle connections. The disadvantage to this choice is that the IBM HTTP Server uses excess resources to keep extra threads available, even during periods of light activity. This choice can only be done on an AIX or Linux operating system.