Does PASOE have an idle *ABL* session timeout?
Unfortunately the OEE timeout settings for PASOE (under "performance tuning and limits") are still confusing in OE 11.7.4 and the documentation is still very vague. I should probably know by now. But can someone tell me if I can set an idle *ABL* session timeout? I would expect the only possible way that an *ABL* session might be timed-out is by playing with the "idle resource timeout" and "idle session timeout". I thought I would ask the question here (before spending a day at trial-and-error).
In the OEE console, the timeouts are quite confusing. The idle "session" timeout in particular seems like it should have a lot more explanation. "Session" is a word that has a large number of meanings within the context of PASOE (and clients of pasoe). I think there are at least four that I can think of off the top of my head (client-side sessions in the openclient, HTTP sessions, session-manager sessions, and ABL sessions).
Labeling something as an "idle session timeout" in OEE is about as helpful as if it was called an "idle smurf timeout". That's my $0.02.
We do not have Idle ABL Sessiontimeout "yet" in PASOE.
We updated the following in our web.xml and now we get the proper "idle" timeout.
<!-- ==================== Default Session Configuration ================= -->
<!-- You can set the default session timeout (in minutes) for all newly -->
<!-- created sessions by modifying the value below. -->
Thanks Roger. But I wouldn't think this would cause the ABL sessions to time out (within an ms-agent process, _mproapsv).
I was hoping there might be an automated feature to cause ABL sessions to automatically be timed out, thereby releasing the memory that is allocated in _mproapsv. (ie. memory for handles, persistent procs, static class members, and so on).
Currently we are trimming inactive ABL sessions using the REST interface in "oemanager". But it seems to me that other Progress customers may want a feature like this to be built into the product. I'm not sure which of the existing timeouts serves this purpose, if any.
I have logged a doc bug to have the description of the idle session timeout updated to be clearer. ADAS-12871.
The openedge.properties.README is clear about which session the properties control. See below.
There appears to be a disconnect between the README and the OE doc that OEM pulls its context help from. As Matt mentioned, Defect ADAS-12871 has been logged for this.
At this time, the only way to terminate an idle ABL session is with REST/JMX call.
There is an existing backlog item for ABL session timeout functionality, but it wouldn't hurt to log an IDEA on communities for this.
Timeout value in milliseconds to determine the frequency with which the
PASOE server checks for idle resources. Any resource (e.g. connection,
agent, or client session) that has not been accessed more recently than
the specified timeout for that property will be terminated. If this property
is set to zero, then idle resource checking is disabled.
Timeout value in milliseconds for an idle SessionManager session.
If a SessionManager session is idle for more than the specified timeout value, then
the session will be deleted when idleResource cleanup is done.
Timeout value in milliseconds for an idle agent.
If an agent is idle for more than the specified timeout value, then
Timeout value in milliseconds between an AppServer client and the Session Manager.
If a connection is idle for more than the specified timeout value, then
the SessionManager will terminate the connection by automatically
disconnecting the connection from the AppServer.
PAUL J. CONNAUGHTON
QA Engineer II, OE Core Database
PROGRESS SOFTWARE CORPORATION
DIRECT +1 781 280 3064 | MOBILE +1 508 254 0465
OK thanks Irfan. That is what I suspected. But given that there is a REST API to trim inactive ABL sessions, it seems like I might be overlooking some property that constrained the ABL session lifetime, based on a sesssion lifetime limit or an idle session timeout. I didn't know if I was overlooking anything..
I suppose that trimming an inactive MS-agent has a similar effect as trimming inactive ABL sessions. (By trimming the agent process, the sessions are implicitly trimmed as well. But restarting the agent again in the future is more costly than restarting an ABL session.)
Currently my idle resource timeout is zero (the default) and I'm little hesitant to mess with that since I think it affects various other resources in addition to the MS-agent. It would be nice if the various resource timeouts were managed independently of each other. I think the way you explained it in the past, the "idle resource" timeout behaves like a gated on or off switch for all of the other timeout properties. That is a bit intimidating, because we don't normally want to risk unintended consequences that might arise from introducing a timeout in an unrelated "broker resource", other than the MS-agent itself.