Kbase P110855: Errors (10893), (11506) and (10899) when making a Web Service request after an AppServer shutdown
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
11/11/2009 |
|
Status: Verified
SYMPTOM(s):
Errors (10893), (11506) and (10899) when making a Web Service request after an AppServer shutdown
Web 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)
Restarted the AppServer Broker that is being used by the Web Service
The SOAP fault is generated only for the first Web Service request after the AppServer is restarted
Subsequent requests to the Web Service work just fine
This only occurs with the Session Free Model of Web Service
The AppServer Broker used by the Web Service has an Operating Mode of State-free
The following JAVA Exceptions appear in the WSA log file
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)
FACT(s) (Environment):
OpenEdge 10.x
All Supported Operating Systems
CAUSE:
This is working as expected.
If 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. This is because of the way that errors are detected when requests fail.
If a request is run using a socket that has been disconnected by the remote node (e.g. the broker has been shut down and brought back up), no error is given when sending the request: the client thinks that the request has been successfully sent. However, when the client attempts to receive the response, the 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).
FIX:
After restarting the AppServer Broker, perform one of the following steps in order to avoid the broken communication between the WSA and the AppServer:
- Re-enable the Web Service by issuing the following commands:
wsaman -name wsa1 -appname YourWebServiceName -disable
wsaman -name wsa1 -appname YourWebServiceName -enable
- OR -
- Reload the WSA by shutting down and restarting the JSE (Tomcat, for instance).