When running the Progress Application Server for OpenEdge (PASOE), after some duration of time, the java process would consume larger and larger chunks of memory and would then start to further consume all CPU. 

This can result in the ABL applications running on the PASOE instance to become unresponsive.

PASOE Java heap memory analysis reveals that a new HTTP Web Session object is created for each anonymous request. 
This session remains in memory for an extended period until it's eventually deleted. 

However with a large number of incoming anonymous requests in a short period of time, the number of anonymous HTTP Web Sessions created on the server can grow significantly, affecting the PASOE responsiveness with, in the worst case scenario, out of memory errors.

 

The PASOE ABL Web App is configured with form authentication.

The client making the anonymous requests doesn't handle HTTP cookies.
 
Some of the Web App resources (URI) are configured to be accessed anonymously, so without the need for user authentication. For example, the Web App contains a URL pattern similar to the following in the oeablSecureity.csv file:

"/rest/_oepingService/_oeping","GET","hasAnyRole('ROLE_PSCUser','ROLE_ANONYMOUS')"

- OR -

"/rest/_oepingService/_oeping","GET","permitAll()"

The issue may appear at first as a Tomcat OS process increase in memory due to a memory leak, but in fact has been concluded to be related to the ABL web application's security configuration, and the calling of URL with anonymous access (permitAll()) such as calling the /rest/_oepingService/_oeping URI.

When using the PASOE and form authentication, the Spring Security stack will track all of the client authentication state using the Tomcat server's JSESSIONID HTTP Web Session.
Tracking the client authentication state includes both anonymous (anonymousUser) client users, and fully authenticated clients, resulting from user-id and password validation.
In an ABL web application running in PASOE, both the authenticated and the anonymous user is always a valid client user-id that can result in a Client-Principal security token being  generated, used for URI access control, and passed to the ABL business application code.
In this way, the business application can distinguish between the ABL code being called by a non-authenticated user versus an authenticated user.
The run-time behavior is such that, Spring Security will ask Tomcat to create a new JSESSIONID HTTP Web Session for every client, expecting that the client will perform in a common way to handle HTTP cookies. This run-time behavior requires the client programmer to always handle cookies property when using any URI in the ABL web application.
Normally the JSESSIONID is passed on subsequent requests between the client and server.
However, when a REST client does not return the server issued cookie, each HTTP request is considered a new client and will create a new JSESSIONID HTTP Web Session for the client by allocating memory. 
Thus, the server's memory will grow over time if the Web Session is not cleaned up properly.
When a REST client does properly handle HTTP cookies, a single HTTP Web Session will be created on the server and reused for each and every HTTP request. In this case there is no increase in server process memory.
 

Progress recommends the handling of HTTP cookies in the clients. This will allow such that, when the PASOE server returns a JSESSIONID cookie that is not blank (delete cookie), the JSSESSIONID cookie value is retained and used on each subsequent HTTP request.
When the PASOE server returns a blank JSESSIONID cookie, the stored cookie is automatically deleted. 
The next HTTP request from the client will not send a JSESSIONID cookie, thus starting the process over again with the new cookie sent by the PASOE server and must be handled properly by the client.

Alternatively, upgrade to OpenEdge 12.8. A new OpenEdge anonymous filter has been added within the Spring Security configuration files which does not generate JSESSIONID cookies for anonymous requests.

• WEB-INF/oeablSecurity.properties – This example file defines a property – exclude.uri.pattern  – that contains the URI(s) that are excluded from the normal "form" HTTP Web Session policy. This means do not generate HTTP Web Sessions for the configured URIs.
• WEB-INF/oeablSecurity.csv – This example file contains explicit access control denial of access to the excluded URIs.
• WEB-INF/spring/formCustomLoginModel.xml – This example file is a modified copy of the standard "form" security policy that imports the URI exclusion configuration.
• WEB-INF/spring/http-exclusions.xml – This example file is a Spring Security HTTP URI configuration that will exclude the configured URI(s) – see exclude.uri.pattern – from the  form" HTTP Web Session policy. No HTTP Web sessions will be created for the client, and no HTTP cookies will be returned to the client.

1. Download the attached .zip file called “FormLoginNoCookieClients.zip” which contains the sample files, to a temp location on your local server.
2. Extract the 'exclude.uri.pattern' property from the sample's oeablSecurity.properties file and add it to your existing ABL web application's oeablSecurity.properties. This sample covers the REST oeping services and the ABL web app's server service.
3. Copy the formCustomLoginModel.xml file into the existing ABL web app's WEB-INF/spring/ directory - (Note: This is a copy of formLoginModel.xml plus the import of the httpexclusions.xml file). This allows the ability to have your own 'form' configuration without it being overwritten by OpenEdge.
4. Copy the http-exclusions.xml file into the existing ABL web app's WEB-INF/spring/ directory. This contains everything you need, and it is advised not to edit this file unless you have a good understanding of Spring Security configurations.
5. Edit the existing WEB-INF/oeablSecurity.properties and change the client.login.model=formCustom – (Note: This uses the WEBINF/spring/formCustomLoginModel.xml configuration).
6. It is optional (but recommended) to edit the existing ABL web application’s oeablSecurity.csv file and explicitly deny access to certain oeping services, to handle the case in event of a configuration error. (Note: Look in the sample for the rules for '/rest/_oepingService/_oeping', '/rest/_oeping', and '/server'. Add those to the existing web application's oeablSecurity.csv file.
7. Restart the PASOE server and check the log files for Spring configuration errors, and resolve as required. Once you have a clean PASOE server startup, return your REST client tests that do not support cookies when calling the oeping or server services.