[Progress Communities] [Progress OpenEdge ABL] Forum Post: RE: Any samples showing how to use Progress.Lang.OERequestInfo?

Status
Not open for further replies.
D

dbeavon

Guest
>> Can you help us understand what exactly are you looking for and whats your use-case ? Hi Irfan, We are finding that certain remote openclients are able to create ad-hoc requests for APSV data that may run indefinitely long (eg. for three hours). But the client-side openclient HTTP timeout can be much shorter than that ... so the openclient will give up and close the connection (eg. after only one hour). At that point the session manager notices that the remote connection was closed, and this fact is printed in the session manager log. It includes the tomcat session ID (but until now I've never known if/how there is a way to retrieve the session ID from custom ABL). Despite the fact that the remote openclient is long-gone, (and the session manager was made aware of the fact) the tomcat session ID remains intact. And it holds onto resources within the ms-agent process. Based on my observations, even after the ABL session finally finishes its work (in three hours), it does NOT appear like the session manager wants to release hold of the ABL session (via the act of trimming-active-sessions for example). In other words, that session's resources seem to be "pinned" as long as the tomcat session ID remains intact (as viewed in the tomcat manager webapp for HTTP sessions). As a side note, our tomcat session timeouts are extremely long (24 hrs) for the sake of compatibility with the legacy "state-free/session-free" APSV connections. To make a long story short, expiring tomcat session ID's seems to be the key to getting PASOE to release hold of certain resources within the ms-agent process. If the tomcat session ID is orphaned, and remains intact for 24 hours then there will be "pinned" resources in the ms-agent for that entire time. Initially I am hoping to simply accumulate session ID's from these ad-hoc requests (based on the a list of usual suspects, as identified from "session:current-request-info:procedureName") . And the session ID's will be cross-referenced periodically against the tomcat manager REST interface. And any of these ad-hoc sessions that are still present after an hour will start triggering emails to the application administrators (along with the related tomcat session ID's and instructions on how to perform clean up via the tomcat "manager" webapp). Hopefully this is clear. Let me know if not. I'm not trying to make things harder than they need to be. The problem is always with the greedy, ad-hoc requests from power users. I think there are some theoretical ways to handle this in ABL too (STOP-AFTER) but it doesn't seem to work reliably. I'd rather inform PASOE about the HTTP session's expiration, and force PASOE to deal with those runaway ABL sessions. Thanks, David

Continue reading...
 
Status
Not open for further replies.
Top