We have a situation where there are occasionally some login failures on our PASOE server.  A certain number of these login failures are "expected" and they happen during the "connect" procedure for session-managed APSV clients (using HTTP sessions in tomcat).  The logins are rejected by using "RETURN ERROR" in the "connect" procedure.

That appears in the msagent log as follows:

[19/10/08@09:20:58.561-0400] P-004732 T-004592 1 AS-240 -- EntryProcedures\SessionConnectProc.p  connect procedure ended with an ERROR condition. (8025)

As I mentioned, our custom PASOE program will reject connections by using "RETURN ERROR" in the "connect" procedure.  This is the same mechanism for rejecting connections that we had used in classic appserver. When the login failures happen, everything behaves as expected from the client application's perspective and the client receives a connectivity exception, as expected.

What is not expected, however, is the way that PASOE behaves after a connection is rejected.  To be more specific, the tomcat HTTP session doesn't appear to be immediately closed.  We have extremely long HTTP session timeouts configured in tomcat (as a workaround for unrelated issues in PASOE that I won't go into here).  And since the connection rejections do not also result in the closing of tomcat HTTP sessions, then those sessions will hang around for a long time.

The tomcat/HTTP sessions themselves are not actually my primary concern.  They consume only a minimal amount of memory and will not drastically impact the server.  What concerns me more is that these sessions will actually cause ABL sessions in the msagent to remain "pinned" in some way.  For whatever reason that I don't fully understand, the related idle ABL session in the msagent cannot be trimmed when needed.  The ABL sessions continue to consume large amounts of memory (perhaps ~50-100 MB or so depending on what the sessions had been used for prior to the failed logins.)   The large amounts of memory aren't released until the tomcat/HTTP sessions finally expire.  It is the sum of these large amounts of ABL session memory from multiple failed logins can become a problem for the PASOE server as a whole.

Sorry for the very long backstory.  This finally brings me to my question.  What is the expected behavior when a "connect" procedure results in a "RETURN ERROR" (rejects a connection)?  Shouldn't the related HTTP session in tomcat be immediately closed?  Is it a challenge for PASOE to make this work?  There have been other instances where I've noticed tomcat sessions being held open for very questionable reasons.  But login failures seem like a pretty straightforward reason for closing the related HTTP session in tomcat and releasing all resources immediately (without relying on a tomcat timeout for the cleanup).