Kbase P152287: Error (11773) with reported WinSock error=10054 when attempting to consume a Web Service from Progre
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
11/09/2009 |
|
Status: Unverified
SYMPTOM(s):
Error (11773) with reported WinSock error=10054 when attempting to consume a Web Service from Progress ABL/4GL
Error receiving Web Service Response: (11773)
Error receiving Web Service Response: Fatal Error: csnet read operation failed (WinSock reported error=10054) (11773)
The error happens intermittently
FACT(s) (Environment):
All Supported Operating Systems
OpenEdge 10.x
Web Services
CAUSE:
WinSock error 10054 is "Connection reset by peer", or "An existing connection was forcibly closed by the remote host". The error means exactly what it says - the remote host closed the connection unexpectedly. This happens when a connection is aborted, and there is no TCP disconnection handshake (fin, fin ack, ack), but instead an rst (reset) flag is sent. A reset flag aborts the connection and can be sent when:
- The device is suddenly stopped, rebooted, or loses its network connection
- The device uses a "hard close"
- A "half-open connection" state occurs. That is, when the device has not been receiving acknowledgements of the data it has sent, or it receives acknowledgement for an unrecognized sequence or ack number, it will send a rst flag to reset the connection. This particular case could have a variety of its own causes, such as misconfigured proxy/firewall or network quality issues resulting in too many dropped packets.
FIX:
Contact the Web Service Provider in order to find out why the socket connection to the web service has been reset by the remote host
Alternatively, another thing to consider is that this does appear to be an underlying network error. Remote procedure calls such as web service executions do contain an inherent level of uncertainty. It could be that the messages are just getting lost due to poor network quality or some other infrequent unreliability that neither the web service consumer nor the web service provider have control over ? some intermittent issue with an intermediate network node. Therefore, it is always a good idea to implement some sort of error handling that performs a retry on the web service request/remote procedure call in a production application environment. Example:
DEFINE VARIABLE viRetryCount AS INTEGER INITIAL 0 NO-UNDO.
REPEAT:
/* Invoke the verification operation. */
RUN VerifyAddressUSA IN hUSAddressVerificationSoap
(INPUT <in-param-1>,
INPUT <in-param-2>,
INPUT <in-param-3>,
...
INPUT <in-param-n>,
OUTPUT <out-param-1) NO-ERROR.
/* Process returned error messages. */
IF ERROR-STATUS:ERROR OR ERROR-STATUS:NUM-MESSAGES > 0 THEN
viRetryCount = viRetryCount + 1.
ELSE
LEAVE.
IF viRetryCount > 2 THEN
LEAVE.
END.
IF viRetryCount > 2 THEN
RETURN <error-message>.
/*** logic continues... ***/