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
<[email protected]> 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 <[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