Feedback
Did this article resolve your question/issue?

   

Article

First request to the REST Web Application returns HTTP 500 when the AppServer is restarted

« Go Back

Information

 
TitleFirst request to the REST Web Application returns HTTP 500 when the AppServer is restarted
URL Name000053165
Article Number000172405
EnvironmentProduct: OpenEdge
Version: 11.2 , 11.3 , 11.4
OS: All supported platforms
Other: REST
Question/Problem Description
Once the AppServer is restarted the first request to an OpenEdge REST Web Application returns HTTP internal server error 500

The first request to an OpenEdge REST Web Application always fails after the AppServer has been restarted
The first request to an OpenEdge REST Service always fails after the AppServer has been restarted

The log file of the deployed OpenEdge REST Web Application shows java.net.SocketException exceptions and errors 7205 7175
Steps to Reproduce
Clarifying Information
 
 
Error MessageHTTP/1.1 500 Internal Server Error

READPACKET IOException : java.net.SocketException: Software caused connection abort: recv failed (Software caused connection abort: recv failed)
DISCONNECT IOException:  java.net.SocketException: Software caused connection abort: socket write error
error deleting session reference = <session-00002|AppServerDC://[IP]:[port]/>
com.progress.open4gl.Open4GLException: Disconnect failure: NULL. (7205)
Exception in AppServerProducer :: Communication layer message: General Error: READPACKET IOException : java.net.SocketException: Software caused connection abort: recv failed (Software caused connection abort: recv failed). (7175)
Defect Number
Enhancement Number
Cause
This is expected behavior. When an error occurs while attempting to run a procedure on a session-free connection, the REST Web Application 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. 
  • When a request is run using a socket that has been disconnected by the remote node - the Broker in this case has been shut down and brought back up, no error is able to be returned when sending the request
  • Given that errors are not detected when sending the request, the client cannot determine if the request was actually sent or not. The client therefore assumes that the request has been successfully sent. 
  • However, when the client attempts to receive the response, the java.net.SocketException exception is thrown
  • As a result, 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 REST Web Application to the Progress Application Server for OpenEdge, first introduced in OpenEdge 11.5. PASOE is a platform that provides REST Web server support for Progress Applications which uses the familiar 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 REST Service and the AppServer consider the following options after restarting the AppServer Broker:

Option 1: Re-enable the REST Service:

$   restman -name restmgr1 -appname YourRESTServiceName -disable
$   restman -name restmgr1 -appname YourRESTServiceName -enable

   
Option 2: Re-enable the REST Service:

Reload the REST Service by restarting the Java Container (e.g. Tomcat).

   
Option 3: Send a test request to the REST Service:

Script a dummy request to be sent to the REST Service 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.

   
Option 4: Send a command to Tomcat to unload and load a specific Service to avoid restarting the entire Tomcat server.

Example: Send a STOP then START command to the Service

  • The admin user with the admin password to connect to the machine
  • localhost running on port 8080 - hange localhost to the correct hostname or IP address and the 8080 port to use the current Tomcat management port
  • Set the path value to path to the service managed by Tomcat
  • Sent the stop command sent to /myapp service: 
curl --user admin:admin http://localhost:8080/manager/text/stop?path=/myapp
  • Then send the start command to the /myapp service:
curl --user admin:admin http://localhost:8080/manager/text/start?path=/myapp

 

Workaround
Notes
Last Modified Date10/15/2020 12:00 PM
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.