Feedback
Did this article resolve your question/issue?

   

Article

Errors 10893, 11506 and 10899 sending a Web Service request after an AppServer shutdown

« Go Back

Information

 
TitleErrors 10893, 11506 and 10899 sending a Web Service request after an AppServer shutdown
URL NameP110855
Article Number000184823
EnvironmentProduct: OpenEdge
Version: 10.x, 11.x
OS: All supported platforms
Other: Classic SOAP Web Service
Question/Problem Description
When the AppServer is restarted between the execution of two requests , error 7175 is part of a series of errors triggered by 10893 and 10899
Errors 10893, 11506 and 10899 sending a SOAP Web Service request after an AppServer shutdown
Java Exceptions are thrown in the WSA log file java.net.SocketException and errors 8409 7175 10929

The SOAP fault is generated only for the first Web Service request after the AppServer is restarted

The first request fails only with the Session Free Model of Web Service and a state-free AppServer
 
Steps to Reproduce
Clarifying Information
The following are true:
  • The WSDL document is still accessible through the WSA
  • The SOAP fault is generated only for the first Web Service request 
  • Subsequent requests to the Web Service work as expected
  • The first request fails only with a Session Free Model of Web Service when the AppServer is restarted
  • The AppServer Broker used by the Web Service has an Operating Mode of State-free
There is no firewall between the WSA and the AppServer as outlined in Article Network idle timeouts prevent Web Service access for inactive sessions 10893, 11506 and 10899

When the AppServer and WSA are on separate servers they cannot always guarantee both will be restarted
Error MessageWeb service operation <operation-name> generated a SOAP Fault. SOAP faultstring is: An error was detected while executing the Web Service request. (10893) (11506)
An error was detected while executing the Web Service request. (10893)
Web service operation <operation-name> generated a SOAP Fault. SOAP faultstring is: <fault-string> (11506)
A network error occurred executing the Web Service application. (10899)

com.progress.ubroker.client.BrokerSystem$BrokerSystemCommunicationsException: Client Communications Failure - java.net.SocketException: Software caused connection abort: recv failed (8409)
Client Communications Failure - <Java Exception> (8409)
DISCONNECT IOException:  java.net.SocketException: Software caused connection abort: socket write error
com.progress.open4gl.Open4GLException: Disconnect failure: NULL.
Error in SOAP request execution: Communication layer message: Client Communications Failure - java.net.SocketException: Software caused connection abort: recv failed (8409). (7175) (10926)
Error in SOAP request execution: Communication layer message: Client Communications Failure - java.io.EOFException (8409). (7175) (10926)
Defect Number
Enhancement Number
Cause
This is expected behaviour. This is due to the way that errors are detected when requests fail. 

When an error occurs while attempting to run a procedure on a session-free connection, the WSA cannot recover from the error by re-trying the request on another connection:
  • The request is run using a socket that has been disconnected by the remote node, the AppServer Broker has been shut down and brought back up in this case
  • No error is returned when sending the request and the client assumes therefore that the request has been successfully sent. 
  • However, when the client then attempts to receive the response, the java.net.SocketException exception is thrown. 
  • Given that errors are not detected when sending the request, the client cannot determine if the request was actually sent or not. This means that the request cannot be retried on another connection because this could cause the request to be run twice (if the first send didn't actually fail).
Resolution

Upgrade to OpenEdge 11.7, 12.2 or later and migrate the Classic OpenEdge Web Application to the Progress Application Server for OpenEdge, first introduced in OpenEdge 11.5. PASOE is a platform that provides Web server support for Progress Applications which uses a Tomcat server that is installed, configured and monitored as a Web Server.   This issue will not occur with PASOE because the server is treated as a single entity.

While migrating from Classic to PASOE is not an immediate solution, to avoid the broken communication between the WSA and the AppServer consider the following options when restarting the AppServer Broker.

Option 1: Re-enable the Web Service:

$   wsaman -name wsa1 -appname YourWebServiceName -disable
$   wsaman -name wsa1 -appname YourWebServiceName -enable

When running the OpenEdge ESB adapter, reload the OpenEdge WebServices ESB container from the ESB container console

$   reload OEContainer

Option 2: Reload the WSA by shutting down and restarting the JSE (Tomcat, for instance).

Option 3: Send a test request to the Web Service to trigger the communication error. Then subsequent requests will not cause an issue.

Script a dummy request to be sent on the restart of the app server to trigger the communication error. Since requests after the first one do not generate the error, this mechanism will allow for normal operation for subsequent requests after the restart.

Additional Considerations:

1.  Review the reasons behind why the AppServer needs to be restarted in the first instance

In some cases, trimming the AppServer agents is an alternative to shutting down the AppServer. In this case the connections from the WSA connection pool will be unaffected since they go through the AppServer Broker.

   What is the autoTrimTimeout value for WebSpeed and AppServer?   
   Is there a way to trim a specific Agent of the Unified Broker ?  
   Which agents are trimmed when using asbman -trimagents command?  

2. Network errors while executing Web services applications can occur for many reasons. If the steps above do not resolve the issue, further troubleshooting of the network and/or the Web services application may be required.

Workaround
Notes
Last Modified Date11/20/2020 7:28 AM
Attachment 
Files
Disclaimer The origins of the information on this site may be internal or external to Progress Software Corporation (“Progress”). Progress Software Corporation makes all reasonable efforts to verify this information. However, the information provided is for your information only. Progress Software Corporation makes no explicit or implied claims to the validity of this information.

Any sample code provided on this site is not supported under any Progress support program or service. The sample code is provided on an "AS IS" basis. Progress makes no warranties, express or implied, and disclaims all implied warranties including, without limitation, the implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample code is borne by the user. In no event shall Progress, its employees, or anyone else involved in the creation, production, or delivery of the code be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample code, even if Progress has been advised of the possibility of such damages.