Jetspeed 2
  1. Jetspeed 2
  2. JS2-995

NPE in ProfilerValve under desktop mode

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.2.0
    • Fix Version/s: 2.2.0
    • Component/s: None
    • Labels:
      None

      Description

      Under desktop mode, sometimes, the following exceptions are logged and the portlet content is not displayed:

      2009-05-07 19:44:19,594 [http-8080-1] ERROR
      org.apache.jetspeed.profiler.impl.ProfilerValveImpl - Exception in
      request pipeline: null
      java.lang.NullPointerException
      at org.apache.jetspeed.om.page.ContentPageImpl.getId(ContentPageImpl.java:469)
      at org.apache.jetspeed.profiler.impl.ProfilerValveImpl.getPageActionAccess(ProfilerValveImpl.java:322)
      at org.apache.jetspeed.profiler.impl.ProfilerValveImpl.invoke(ProfilerValveImpl.java:247)
      at org.apache.jetspeed.pipeline.JetspeedPipeline$Invocation.invokeNext(JetspeedPipeline.java:167)
      at org.apache.jetspeed.localization.impl.LocalizationValveImpl.invoke(LocalizationValveImpl.java:170)
      at org.apache.jetspeed.pipeline.JetspeedPipeline$Invocation.invokeNext(JetspeedPipeline.java:167)
      at org.apache.jetspeed.security.impl.AbstractSecurityValve$1.run(AbstractSecurityValve.java:138)
      at java.security.AccessController.doPrivileged(Native Method)
      at javax.security.auth.Subject.doAsPrivileged(Subject.java:454)
      at org.apache.jetspeed.security.JSSubject.doAsPrivileged(JSSubject.java:179)
      at org.apache.jetspeed.security.impl.AbstractSecurityValve.invoke(AbstractSecurityValve.java:132)
      at org.apache.jetspeed.pipeline.JetspeedPipeline$Invocation.invokeNext(JetspeedPipeline.java:167)
      at org.apache.jetspeed.capabilities.impl.CapabilityValveImpl.invoke(CapabilityValveImpl.java:127)
      at org.apache.jetspeed.pipeline.JetspeedPipeline$Invocation.invokeNext(JetspeedPipeline.java:167)
      at org.apache.jetspeed.container.url.impl.PortalURLValveImpl.invoke(PortalURLValveImpl.java:67)
      at org.apache.jetspeed.pipeline.JetspeedPipeline$Invocation.invokeNext(JetspeedPipeline.java:167)
      at org.apache.jetspeed.pipeline.JetspeedPipeline.invoke(JetspeedPipeline.java:146)
      at org.apache.jetspeed.engine.JetspeedEngine.service(JetspeedEngine.java:225)

        Activity

        Hide
        Woonsan Ko added a comment -

        Thank you so much for the stable fix.

        Show
        Woonsan Ko added a comment - Thank you so much for the stable fix.
        Hide
        Randy Watler added a comment -

        Patched by backing out this change and an older change, (JS2-768), to restore more stable operation in the ProfilerValve implementation that managed portal site session state.

        SVN commit: 773753

        Show
        Randy Watler added a comment - Patched by backing out this change and an older change, ( JS2-768 ), to restore more stable operation in the ProfilerValve implementation that managed portal site session state. SVN commit: 773753
        Hide
        Randy Watler added a comment -

        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:
        >
        > #209~216:
        > PortalSiteSessionContext sessionContext =
        > (PortalSiteSessionContext)request.getSessionAttribute(PORTAL_SITE_SESSION_CONTEXT_ATTR_KEY);
        > String pipeline = request.getPipeline().getName();
        > if ((sessionContext == null) ||
        > !sessionContext.isValid() || hasPipelineChanged(pipeline,
        > sessionContext.getPipeline()))
        >

        { > sessionContext = portalSite.newSessionContext(); > sessionContext.setPipeline(pipeline); > > request.setSessionAttribute(PORTAL_SITE_SESSION_CONTEXT_ATTR_KEY, > sessionContext); > }

        > #228:
        > PortalSiteRequestContext requestContext =
        > sessionContext.newRequestContext(locators, requestFallback,
        > useHistory);
        > #244:
        > request.setPage(new
        > ContentPageImpl(requestContext.getManagedPage()));
        >
        >
        > 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.
        >

        Show
        Randy Watler added a comment - 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: > > #209~216: > PortalSiteSessionContext sessionContext = > (PortalSiteSessionContext)request.getSessionAttribute(PORTAL_SITE_SESSION_CONTEXT_ATTR_KEY); > String pipeline = request.getPipeline().getName(); > if ((sessionContext == null) || > !sessionContext.isValid() || hasPipelineChanged(pipeline, > sessionContext.getPipeline())) > { > sessionContext = portalSite.newSessionContext(); > sessionContext.setPipeline(pipeline); > > request.setSessionAttribute(PORTAL_SITE_SESSION_CONTEXT_ATTR_KEY, > sessionContext); > } > #228: > PortalSiteRequestContext requestContext = > sessionContext.newRequestContext(locators, requestFallback, > useHistory); > #244: > request.setPage(new > ContentPageImpl(requestContext.getManagedPage())); > > > 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. >
        Hide
        Woonsan Ko added a comment -

        Randy, would you please review my commit on this issue?

        Show
        Woonsan Ko added a comment - Randy, would you please review my commit on this issue?

          People

          • Assignee:
            Randy Watler
            Reporter:
            Woonsan Ko
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development