You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openwebbeans.apache.org by Martin Koci <ma...@gmail.com> on 2010/10/01 20:42:31 UTC
NPE in InterceptorHandler
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čí
Re: conversation.getInUsed() and phase listener (was: Re: NPE in
InterceptorHandler)
Posted by Martin Koci <ma...@gmail.com>.
Hi,
yes, exactly, I just put code from WebBeansPhaseListener.afterPhase into
finally block in filter with an extra null check.
1) Servlet filter must be in web.xml (PhaseListener is registered from
any faces-config.xml on classpath) -> users must register it in each
project in web.xml:
<filter>
<filter-class>org.apache.webbeans.jsf.WebBeansJSFFilter</filter-class>
<filter-name>WebBeansJSFFilter</filter-name>
</filter>
<filter-mapping>
<filter-name>WebBeansJSFFilter</filter-name>
<servlet-name>Faces Servlet</servlet-name>
</filter-mapping>
Currently OWB examples or documentation don't contain this registration.
2) Then we should move all conversation code to filter because
specification says: "The conversation scope is active: during all
standard lifecycle phases of any JSF faces or >>>non-faces request<<<" -
from "6.7.4. Conversation context lifecycle".
https://issues.apache.org/jira/browse/OWB-467
Regards,
Martin Kočí
Rohit Kelapure píše v Út 05. 10. 2010 v 08:42 -0400:
> Martin,
>
> Checking in a finally block sounds like a good idea.
> The only thing I would add is to check if conversation == null before
> calling conversation.setInUsed(false);
>
> --Thanks,
> Rohit
>
>
>
> On Mon, Oct 4, 2010 at 5:16 PM, Martin Koci
> <ma...@gmail.com> wrote:
> > 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 <ma...@gmail.com> wrote:
> >>
> >> > From: Martin Koci <ma...@gmail.com>
> >> > Subject: NPE in InterceptorHandler
> >> > To: dev@openwebbeans.apache.org
> >> > 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čí
> >> >
> >> >
> >>
> >>
> >>
> >>
> >
> >
> >
>
Re: conversation.getInUsed() and phase listener (was: Re: NPE in InterceptorHandler)
Posted by Rohit Kelapure <ke...@gmail.com>.
Martin,
Checking in a finally block sounds like a good idea.
The only thing I would add is to check if conversation == null before
calling conversation.setInUsed(false);
--Thanks,
Rohit
On Mon, Oct 4, 2010 at 5:16 PM, Martin Koci
<ma...@gmail.com> wrote:
> 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 <ma...@gmail.com> wrote:
>>
>> > From: Martin Koci <ma...@gmail.com>
>> > Subject: NPE in InterceptorHandler
>> > To: dev@openwebbeans.apache.org
>> > 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čí
>> >
>> >
>>
>>
>>
>>
>
>
>
Re: conversation.getInUsed() and phase listener (was: Re: NPE in InterceptorHandler)
Posted by Mark Struberg <st...@yahoo.de>.
good catch!
Is there a quick fix before I reroll the 1.0.0 release?
LieGrue,
strub
--- On Mon, 10/4/10, Martin Koci <ma...@gmail.com> wrote:
> From: Martin Koci <ma...@gmail.com>
> Subject: conversation.getInUsed() and phase listener (was: Re: NPE in InterceptorHandler)
> To: dev@openwebbeans.apache.org
> 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 <ma...@gmail.com>
> wrote:
> >
> > > From: Martin Koci <ma...@gmail.com>
> > > Subject: NPE in InterceptorHandler
> > > To: dev@openwebbeans.apache.org
> > > 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čí
> > >
> > >
> >
> >
> >
> >
>
>
>
conversation.getInUsed() and phase listener (was: Re: NPE in
InterceptorHandler)
Posted by Martin Koci <ma...@gmail.com>.
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 <ma...@gmail.com> wrote:
>
> > From: Martin Koci <ma...@gmail.com>
> > Subject: NPE in InterceptorHandler
> > To: dev@openwebbeans.apache.org
> > 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čí
> >
> >
>
>
>
>
Re: NPE in InterceptorHandler
Posted by Mark Struberg <st...@yahoo.de>.
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 <ma...@gmail.com> wrote:
> From: Martin Koci <ma...@gmail.com>
> Subject: NPE in InterceptorHandler
> To: dev@openwebbeans.apache.org
> 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čí
>
>