myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Freedman (JIRA)" <...@myfaces.apache.org>
Subject [jira] Updated: (PORTLETBRIDGE-58) Race condition BridgeImpl in multi-threaded environment
Date Thu, 29 Jan 2009 23:23:59 GMT

     [ https://issues.apache.org/jira/browse/PORTLETBRIDGE-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Michael Freedman updated PORTLETBRIDGE-58:
------------------------------------------

       Resolution: Fixed
    Fix Version/s: 2.0.0
                   1.0.0
           Status: Resolved  (was: Patch Available)

Fixed by removing use of the shared private data member holding onto the Lifecycle object.
 Instead its created per request.

> Race condition BridgeImpl in multi-threaded environment
> -------------------------------------------------------
>
>                 Key: PORTLETBRIDGE-58
>                 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-58
>             Project: MyFaces Portlet Bridge
>          Issue Type: Bug
>          Components: Impl
>    Affects Versions: 1.0.0-alpha-3, 1.0.0-beta
>         Environment: Pluto 1.1.5
> JSF 1.2 / RI
>            Reporter: Stephan Voigt
>            Assignee: Michael Freedman
>            Priority: Critical
>             Fix For: 1.0.0, 2.0.0
>
>         Attachments: jira_58_and_61.patch
>
>
> The implementation in BridgeImpl delegates the calls to the JSF Phases to a initially
created LifeCycle instance (member of BrideImpl).
> In order to implement the LifeCycle acc. JSR-301 all JSF-Phases except RENDER_RESPONSE
are suppressed using a PhaseListener which calls renderResponse on the current FacesContext,
so that the further phase processing stops.
> The PhaseListener is registered and unregistered in doFacesRender() during a render request.
> The problem: when executed in multiple threads, calls to doFacesRequest (ActionRequests)
use the same LifeCycle instance, which causes a race condition. The processing of the portlet
action will canceled for that request.
> We reproduced that behavior in our environment (JSF-RI, Pluto 1.1.5, PortletBridge 1.0.0-alpha-3,
beta1) using loadtests with 3 or more parallel threads.
> The problematic code-passage in BridgeImpl (see addPhaseListener and removePhaseListener
calls):
> ...
>  private void doFacesRender(RenderRequest request,  RenderResponse response, FacesContext
context, Lifecycle lifecycle, String scopeId,
>       List <String> preExistingAttributes)
>     throws BridgeException, BridgeUninitializedException, NullPointerException
>   {
> ...
>     if (context.getViewRoot() == null)
>     {
>       // add self as PhaseListener to prevent action phases from
>       // executing
>       lifecycle.addPhaseListener(this);
>       try
>       {
>         lifecycle.execute(context);
>       }
>       catch (Exception e)
>       {
> ....
>       }
>       finally
>       {
>         lifecycle.removePhaseListener(this);
>       }
> ....
> In order to solve the problem, we patched the BridgeImpl class in that way it uses a
static configuration for the LifeCycle instance with one enabled Phase-Listener. The decision
when the request processing should be stopped (via calling renderResponse() on the FacesContext)
is handled using a ThreadLocal flag indicating the mode (Action/Render) of the current BridgeRequest.
> Please let me know, if I should provide a corresponding patch set (based on the beta-1
code line) or if the problem will be solved in a different manner.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message