I've noticed that ABL sessions in an ms-agent process can remain stuck in memory over time. If they are pinning resources, like memory, then this will gradually detract from what is available .
Notice above that the msagent process is taking 4 GB. That memory is almost entirely due to an IDLE session ID 697. (its memory utilization is vastly understated in the OEE console but that is another issue). In our environment we are trimming idle sessions all day long on 30 minute intervals, but session ID 697 refuses to be trimmed.
Whenever this happens, I can use the tomcat "manager" webapp and find an idle *HTTP* session that was never properly disconnected (ie. the client application must have been shut down in a way that wasn't graceful).
From tomcat "manager" webapp, I am given the ability to expire HTTP sessions pre-emptively (before the regularly configured HTTP session timeout). When the HTTP session is expired in that way, then some internal tie is broken which had existed between the HTTP session and the ABL session. And the ABL session is finally able to be trimmed via the oemanager REST interface.
To make a long story short, when the HTTP session is expired (preemptively) then it is possible for an ABL session to be trimmed. The ABL session would otherwise be pinned in memory for a long period of time. This leads me to my question. From ABL code is there a way to gain access to the related HTTP session that is provided by tomcat?
For example, could I dynamically change the current HTTP session timeout from a given appserver procedure? I would like it if some procedures could have shorter HTTP session timeouts than others. This would only be needed for certain unusual and long-running procedures (reports, for example).
Here is a link to show that webapps can do this type of thing directly from java.
stackoverflow.com/.../how-to-set-session-timeout-dynamically-in-java-web-applications
(It appears they can use the setMaxInactiveInterval - tomcat.apache.org/.../HttpSession.html ).
I have not found a way to interact with the HTTP session directly (from ABL code). The only thing I found was some read-only properties (Progress.Lang.OERequestInfo ) that are accessible from SESSION:CURRENT-REQUEST-INFO .
Any help would be appreciated. I realize that there are some layers of indirection between tomcat and the ABL code running in the MS-agent. Perhaps Progress doesn't even want me to know the HTTP session that I use from one round-trip to the next (APSV ). But knowing the HTTP session and interacting with it could help us to avoid problems when clients are terminating/disconnecting in a way that is not very graceful. The types of clients that are prone to terminating in this way may need to have their HTTP session-timeouts shortened programmatically.
Hope this is clear. Thanks,
David
PS. The following is shown in the PASOE session-manager's log when remote clients are not gracefully disconnected. If we see this, then it is possible that the related server memory will be pinned for a while (at least until the HTTP session is timed out within tomcat).
12:49:54.825/406187373 [thd-20] ERROR c.p.appserv.adapters.apsv.Request - APSV(6EAD798526514531062362F4A78CB5AEF1834FB500E2.oepas1) : IOException while processing request : org.apache.catalina.connector.ClientAbortException: java.io.IOException: An established connection was aborted by the software in your host machine. (18318) 12:49:54.828/406187376 [thd-20] ERROR c.p.appserv.adapters.apsv.Request - APSV(6EAD798526514531062362F4A78CB5AEF1834FB500E2.oepas1) : An error occurred processing the POST request : Unexpected error : org.apache.catalina.connector.ClientAbortException: java.io.IOException: An established connection was aborted by the software in your host machine. (18320)
I would not expect this to be possible from the AVM given that it and PASOE / Spring run in separate processes. I believe that Spring handles the HTTP sessions (not Tomcat) so you could look further into that.
That said, the approaches in the SO post you linked to should be possible with PASOE.
For APSV connections the HTTP Session existence is controlled inside the transport itself. All other transports are controlled via Spring and the Tomcat session timeout.
The APSV transport should obviously be terminating those HTTP sessions when the client disconnects. The fallback is to allow TC to harvest the expired sessions later. The better case is to cleanup on client disconnect and ensure the clients always disconnect. It is possible to disable the use of HTTP Sessions in the conf/openedge.properties configuration (useHTTPSessions) and test your application. Note: this setting does not affect any transport other then APSV. If changing that property does not affect, or resolve, this bad behavior for you we need to know.
Hi Michael, thanks for the response.
Yes we use APSV transport, and yes, there are clients that disconnect ungracefully for a variety of reasons. We can minimize some of that but only to an extent. In the end, the health of the PASOE server shouldn't be affected when client connections are dropped unexpectedly.
We use HTTP sessions for APSV. This is the default these days, as I recall. And it seemed to be the way to support our load-balancing requirements (with cookie persistence).
FYI ... One of the factors that makes the problem worse than it should be is that the web.xml's session timeout needs to be very high (at least 24 hours). Otherwise the "state-free/session-free" openclients for .Net would crash because the long-lived client-side connection would become invalidated/corrupted. I can point you to that KB if you want to see it.
So I'd like a way to programmatically adjust the default session timeout (from 24 hours down to a fraction of that), depending on the specific type of work that is being done.
I see that the tomcat "manager" app also has a REST interface that can be used for expiring sessions... so I suppose we could program the "administrative" expiration of certain types of sessions after-the-fact. But it would much prefer it if the TC session timeout could be specified up-front from ABL code.
(Another workaround I discovered is to create multiple webapps, where each has its own web.xml with its own default session timeout. But this seems like a substantial overhead just to change the HTTP session timeout.)