The profiler valve should not be attaching/detaching portal site session state in the middle of a session unless there is some discontinuity that invalidates it. The commit here, 772985, is not poor in itself, but might not be addressing the root of the issue. I would prefer to continue resetting the internal state of the portal site component on session state change if possible.
Am investigating why the session is being reset on pipeline change in the profiler valve. This forcing the problem since the desktop configuration uses multiple pipelines simultaneously... something the profiler valve is not properly designed for. Am also looking at why the desktop ajax pipeline includes the profiler valve since this is a major contributor to the multiple pipeline concurrency.
Here is the related background information from Woonsan on the race conditions in profiler valve:
> In the ProfilerValveImpl, there are the following lines:
> PortalSiteSessionContext sessionContext =
> String pipeline = request.getPipeline().getName();
> if ((sessionContext == null) ||
> !sessionContext.isValid() || hasPipelineChanged(pipeline,
> sessionContext = portalSite.newSessionContext();
> PortalSiteRequestContext requestContext =
> sessionContext.newRequestContext(locators, requestFallback,
> Here's an error scenario:
> - There are two simultaneous requests from one browser instance
> (which requests will share a session.)
> - One thread (T1) for one request is running just before #244.
> - Another thread (T2) for another request is running just before #216.
> Because T2 invokes session.setAttribute(), which will result
> valueUnbound() event for the previously stored session object.
> The event will invoke valueUnbound() method of sessionContext
> which is being used by T1.
> - When T1 runs #244, then it will meet NPE.
> requestContext.getManagedPage() -->
> sessionContext.getManagedPage() --> sessionContext.getSiteView()
> However, the profileLocator has gone! Because valueUnbound()
> method cleared it.