Requests for HttpSessions in WAS/CEA result in the creation of a SipApplicationSession. We normally disable session timeout in sip.xml:
<session-config>
<javaee:session-timeout>0</javaee:session-timeout>
</session-config>
and let e4ss handle invalidating sessions explicitly. If there are no SipSessions associated with a SipApplicationSession created implicitly for an HttpSession, the normal e4ss session invalidation mechanism is not executed. The SipApplicationSession therefore leaks. This is particularly noticeable with JSPs, since JSPs create HttpSessions unless explicitly told not to. This behavior can be disabled by adding " <%@ page session="false" %>" to the JSP.
This issue has been filed with IBM as PMR 50254: https://www-946.ibm.com/support/servicerequest/readPMR.action?pmrNum=50254&branch=122&retainCountryCode=000
Pending a resolution on the PMR, we will disable session creation on our test JSPs to eliminate the leaks in the test suite. This is not a long-term solution, since a converged app could easily require http sessions.
Related changes we may want to consider include:
1) Applications that use EChartsProxyServlet rather than EChartsSipServlet do not currently generate AppSessionLifecycleEvent monitor events. These applications include ucf, rerouteUponFailure, registrar, proxyRequest, and ccf from our test suite. Leaks in these apps can still be detected through heap analysis, but adding the same kind of SipApplicationSession created/destroyed events found in EChartsSipServlet-based apps may make future problems easier to spot.
2) Some of the older applications in the test suite include a check to ensure that application sessions are only perpetually extended (when the container attempts to expire them) if they include at least one SIP session. For example, UCFServlet.sessionExpired(...) looks like:
public final void sessionExpired(SipApplicationSessionEvent sase) {
SipApplicationSession sas = sase.getApplicationSession();
Iterator sessions = sas.getSessions("SIP");
while (sessions.hasNext()) {
SipSession ss = (SipSession) sessions.next();
if (! ss.isReadyToInvalidate()) {
sas.setExpires(3);
return;
}
}
}
We may want to add similar logic to EChartsSipServlet.sessionExpired(...).
Proposed change:
1) change sip.xml to set session-timeout to non-zero (Goldilocks interval)
2) change EChartsSipServlet.sessionExpired() to call SAS.getSessions(). If iterator.next() != null, then extend the expiration
3) change archetype to include sample jsp (in test?), showing and documenting session=false