good catch!

Is there a quick fix before I reroll the 1.0.0 release?

LieGrue,
strub

--- On Mon, 10/4/10, Martin Koci <[email protected]> wrote:

> From: Martin Koci <[email protected]>
> Subject: conversation.getInUsed() and phase listener (was: Re: NPE in 
> InterceptorHandler)
> To: [email protected]
> Date: Monday, October 4, 2010, 9:16 PM
> Hi,
> 
> I tracked down how conversation can be locked forever. It
> is simple:
> 
> 1) WebBeansPhaseListener.beforePhase (before restoreView):
> sets inUsed
> to true
> 
> 2) JSF lifecycle  throws a exception and servlet
> container shows http
> 500 error page
> 
> 3) WebBeansPhaseListener.afterPhase will be never called
> to
> setInUse(false)
> 
> You can try in with jsf2sample - just put throw new NPE()
> in
> ConversationData.getNumber()
> 
> 
> JSF PhaseListener is probably not the safe place for
> handling such
> locks. JSF cannot guarantee that there will be render
> response phase as
> reaction to faces request. At least this is true for
> cases:
> 1) Faces Request generates Non-Faces Response
> (facesContext.responseComplete()) - see "Request Processing
> Lifecycle"
> in JSF spec
> 2) error page (for example pure JSP based) as reaction to
> exception
> (<error-page> element in web.xml)
> 3) bug in JSF implementation which makes lifecycle crash
> (for example
> bug in myfaces :) ) 
> 
> 
> This needs something more robust, something like finally {}
> with some
> sort of lock timeout. At first sight
> org.apache.webbeans.jsf.WebBeansJSFFilter looks like the
> right place. I
> think that servlet container must propagate exception up in
> filter chain
> and we can put there:
> 
> try {
>            
> chaindoFilter(request, responseWrapper);
>         } finally {
>            
> conversation.setInUsed(false)    
>         }
> 
> 
> WDYT?
> 
> 
> Regards,
> 
> Kočičák
> 
> 
> 
> Mark Struberg píše v Pá 01. 10. 2010 v 21:51 +0000:
> > Hi Martin!
> > 
> > Please fill a Jira to track this issue!
> > Just in case to keep track of the status.
> > 
> > txs and LieGrue,
> > strub
> > 
> > --- On Fri, 10/1/10, Martin Koci <[email protected]>
> wrote:
> > 
> > > From: Martin Koci <[email protected]>
> > > Subject: NPE in InterceptorHandler
> > > To: [email protected]
> > > Date: Friday, October 1, 2010, 6:42 PM
> > > Hi,
> > > 
> > > I do some stress testing and accidentally this
> NPE
> > > happens:
> > > 
> > > java.lang.NullPointerException
> > >
> java.util.ArrayList.<init>(ArrayList.java:131)
> > >
> org.apache.webbeans.intercept.InterceptorHandler.invoke(InterceptorHandler.java:256)
> > >
> org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.invoke(NormalScopedBeanInterceptorHandler.java:98)
> > > com.foo.bazz.Clazz$$_javassist_157.getFoo()
> > >
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native
> > > Method)
> > >
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> > >
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> > > 
> > > 
> > > OWB build-up from trunk two weeks ago,
> problematic line 256
> > > contains:
> > > 
> > > List<InterceptorData>
> filteredInterceptorStack = new
> > >
> ArrayList<InterceptorData>(this.interceptedMethodMap.get(method));
> > > 
> > > Is this something what was fixed recently or
> should I
> > > create an issue?
> > > I'm rerunning tests with current OWB trunk right
> now.
> > > 
> > > 
> > > Other issue is that after this NPE occurs,
> subsequents
> > > requests obtains
> > > ConversionBusyException - probably some kind of
> lock is not
> > > released if
> > > lifecycle ends with error.
> > > 
> > > 
> > > Thanks,
> > > 
> > > 
> > > Martin Kočí
> > > 
> > > 
> > 
> > 
> >       
> > 
> 
> 
> 



Reply via email to