Details
-
Bug
-
Status: Closed
-
Normal
-
Resolution: Fixed
-
3.2.3
-
None
-
None
-
Platform Sprint 144
Description
IIUC, HstDelegateeFilterBean.processResolvedSiteMapItem(...) or HstFilter.processResolvedSiteMapItem(...) in older versions is supposed to invoke {{cleanupResourceLifecycleManagements if it cannot process the pipeline and it has to just return.
In other words, it has to invoke cleanupResourceLifecycleManagements if it either returns or throws an exception before processing a pipeline.
However, I found out there's one potential corner case by this block:
if (resolvedSiteMapItem.getErrorCode() > 0) { try { log.info("The resolved sitemap item for {} has error status: {}", containerRequest , Integer.valueOf(resolvedSiteMapItem.getErrorCode())); res.sendError(resolvedSiteMapItem.getErrorCode()); } catch (IOException e) { if (log.isDebugEnabled()) { log.warn("Exception invocation on sendError().", e); } else if (log.isWarnEnabled()) { log.warn("Exception invocation on sendError() : {}", e.toString()); } } // we're done: return; }
The above code is located before processing a pipeline, but never does the clean up.
As a result, if the following line (L#613) returns a non-null resolvedSiteMapItem without exception but the resolvedSiteMapItem has non zero error code setting, then any JCR session used the sitemap item handler wouldn't be cleaned up.
resolvedSiteMapItem = processHandlers(resolvedSiteMapItem, siteMapItemHandlerFactory , containerRequest, res, filterChain);
This problem may affect Hippo CMS 7.8, 7.9, 10 and 11.0 (before HSTTWO-3795 was fixed).
Attachments
Issue Links
- relates to
-
HSTTWO-3795 HstLinkProcessor using HstRequestContext#getSession() leads to jcr session leak
- Closed
-
HSTTWO-3861 Backport to 7.9 - Corner case when session leaked in sitemap item handler
- Closed