You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by David Birch <da...@gmail.com> on 2009/03/12 06:12:11 UTC
Issue with ResourceServlet
Hi, we've been getting an intermittent error with Trinidad that i think i
have traced to the logic for resource retrieval. From following the code of
ResourceServlet i can see there is an expectation by some classes it calls
(mostly ResourceLoader subclasses) of a FacesContext to exist, i can see
there is code at the very start of the servlet that creates the FacesContext
if one doesn't already exist, though i think there must be at least the
following scenarios to consider;
(a) thread(s) for ResourceServlet are completely different to the initial
page creation thread, and thus a faces context is created & so subsequent
gets on it are ok
(b) thread(s) for ResourceServlet are executed with the same thread as for
the initial page creation, and for whatever reason the FacesContext hasn't
yet been fully cleaned up & is still attached & so access is ok.
(c) thread(s) for ResourceServlet hit the unlucky scenario where the thread
still has a FacesContext left in it, and so ResourceServlet doesn't create
one, but then a call later on in a class invoked by ResourceServlet tries to
use the FacesContext & none exists
The problem generally manifests much like the stacktrace below, with a null
pointer resulting from there not being a valid faces context & the resource
servlet not being able to determine the locale.
at
weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:42)
at
weblogic.servlet.internal.RequestEventsFilter.doFilter(RequestEventsFilter.java:27)
at
weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:42)
at
weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3496)
at
weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
at weblogic.security.service.SecurityManager.runAs(Unknown Source)
at
weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2180)
at
weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2086)
at
weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1406)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:173)
Caused by: java.lang.ExceptionInInitializerError
at
org.apache.myfaces.trinidadinternal.resource.CoreRenderKitResourceLoader.<init>(CoreRenderKitResourceLoader.java:55)
... 59 more
Caused by: java.lang.NullPointerException
at
org.apache.myfaces.trinidadinternal.resource.CoreRenderKitResourceLoader.getLocale(CoreRenderKitResourceLoader.java:94)
at
org.apache.myfaces.trinidadinternal.resource.CoreRenderKitResourceLoader.getLocaleElementsURI(CoreRenderKitResourceLoader.java:80)
at
org.apache.myfaces.trinidadinternal.resource.LocaleElementsResourceLoader.<clinit>(LocaleElementsResourceLoader.java:113)
... 60 more
Without knowing the code very well i'm not sure of the best solution (ours
is temporarily to force a default for the locale in the ResourceLoaders),
but i did notice this isn't logged very well (i added extra logging to get
this trace), and also that the Null ResourceLoaders (i.e. can't be
created/init'd) are cached - perhaps only good ResourceLoaders should be
cached ?
The issue seems more prevalent on multi-cpu/core machines, and is highly
reproduceable on x86_64 linux, but on our other enviros - Solaris Sparc &
windows we rarely see it.
Any ideas/suggestions?
thanks
David
Re: Issue with ResourceServlet
Posted by Scott O'Bryan <da...@gmail.com>.
I sent this on my iphone, but I didn't see it come through so I'll resend...
I don't buy usecase (b) and (c). In J2EE, each thread will do one piece
of work at a time. The thread *SHOULD* complete before it starts
another. It is true that multiple threads may hit a single class
instance at the same time, but the FacesContext should be isolated to a
single thread and should be cleaned up before a new FacesContext is found.
Is this NOT happening?
Scott
Matthias Wessendorf wrote:
> Hi David,
>
> you said you see the issues on you x86_64 linux box with your application.
> My question is now, do you see that with the plain vanilla 1.2.10 demo
> application too ?
> Eventually I am also interested in the WLS version that you are using.
>
> Can you also create a jira ticket, so that we can keep track of it ?
>
> Thanks,
> Matthias
>
> On Thu, Mar 12, 2009 at 6:12 AM, David Birch <da...@gmail.com> wrote:
>
>> Hi, we've been getting an intermittent error with Trinidad that i think i
>> have traced to the logic for resource retrieval. From following the code of
>> ResourceServlet i can see there is an expectation by some classes it calls
>> (mostly ResourceLoader subclasses) of a FacesContext to exist, i can see
>> there is code at the very start of the servlet that creates the FacesContext
>> if one doesn't already exist, though i think there must be at least the
>> following scenarios to consider;
>>
>> (a) thread(s) for ResourceServlet are completely different to the initial
>> page creation thread, and thus a faces context is created & so subsequent
>> gets on it are ok
>>
>> (b) thread(s) for ResourceServlet are executed with the same thread as for
>> the initial page creation, and for whatever reason the FacesContext hasn't
>> yet been fully cleaned up & is still attached & so access is ok.
>>
>> (c) thread(s) for ResourceServlet hit the unlucky scenario where the thread
>> still has a FacesContext left in it, and so ResourceServlet doesn't create
>> one, but then a call later on in a class invoked by ResourceServlet tries to
>> use the FacesContext & none exists
>>
>> The problem generally manifests much like the stacktrace below, with a null
>> pointer resulting from there not being a valid faces context & the resource
>> servlet not being able to determine the locale.
>>
>> at
>> weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:42)
>> at
>> weblogic.servlet.internal.RequestEventsFilter.doFilter(RequestEventsFilter.java:27)
>> at
>> weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:42)
>> at
>> weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3496)
>> at
>> weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
>> at weblogic.security.service.SecurityManager.runAs(Unknown Source)
>> at
>> weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2180)
>> at
>> weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2086)
>> at
>> weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1406)
>> at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
>> at weblogic.work.ExecuteThread.run(ExecuteThread.java:173)
>> Caused by: java.lang.ExceptionInInitializerError
>> at
>> org.apache.myfaces.trinidadinternal.resource.CoreRenderKitResourceLoader.<init>(CoreRenderKitResourceLoader.java:55)
>> ... 59 more
>> Caused by: java.lang.NullPointerException
>> at
>> org.apache.myfaces.trinidadinternal.resource.CoreRenderKitResourceLoader.getLocale(CoreRenderKitResourceLoader.java:94)
>> at
>> org.apache.myfaces.trinidadinternal.resource.CoreRenderKitResourceLoader.getLocaleElementsURI(CoreRenderKitResourceLoader.java:80)
>> at
>> org.apache.myfaces.trinidadinternal.resource.LocaleElementsResourceLoader.<clinit>(LocaleElementsResourceLoader.java:113)
>> ... 60 more
>>
>> Without knowing the code very well i'm not sure of the best solution (ours
>> is temporarily to force a default for the locale in the ResourceLoaders),
>> but i did notice this isn't logged very well (i added extra logging to get
>> this trace), and also that the Null ResourceLoaders (i.e. can't be
>> created/init'd) are cached - perhaps only good ResourceLoaders should be
>> cached ?
>>
>> The issue seems more prevalent on multi-cpu/core machines, and is highly
>> reproduceable on x86_64 linux, but on our other enviros - Solaris Sparc &
>> windows we rarely see it.
>>
>> Any ideas/suggestions?
>>
>> thanks
>>
>> David
>>
>
>
>
>
Re: Issue with ResourceServlet
Posted by Scott O'Bryan <da...@gmail.com>.
I'm not sure I understand this issue actually. A thread can only
perform one task at a time, so your third scenario should be
impossiblebecause the FacesContext should be unbound before the thread
processes another task.
Are you using IBM's vm?
Sent from my iPhone
On Mar 12, 2009, at 2:32 AM, Matthias Wessendorf <ma...@apache.org>
wrote:
> Hi David,
>
> you said you see the issues on you x86_64 linux box with your
> application.
> My question is now, do you see that with the plain vanilla 1.2.10 demo
> application too ?
> Eventually I am also interested in the WLS version that you are using.
>
> Can you also create a jira ticket, so that we can keep track of it ?
>
> Thanks,
> Matthias
>
> On Thu, Mar 12, 2009 at 6:12 AM, David Birch <da...@gmail.com>
> wrote:
>> Hi, we've been getting an intermittent error with Trinidad that i
>> think i
>> have traced to the logic for resource retrieval. From following the
>> code of
>> ResourceServlet i can see there is an expectation by some classes
>> it calls
>> (mostly ResourceLoader subclasses) of a FacesContext to exist, i
>> can see
>> there is code at the very start of the servlet that creates the
>> FacesContext
>> if one doesn't already exist, though i think there must be at least
>> the
>> following scenarios to consider;
>>
>> (a) thread(s) for ResourceServlet are completely different to the
>> initial
>> page creation thread, and thus a faces context is created & so
>> subsequent
>> gets on it are ok
>>
>> (b) thread(s) for ResourceServlet are executed with the same thread
>> as for
>> the initial page creation, and for whatever reason the FacesContext
>> hasn't
>> yet been fully cleaned up & is still attached & so access is ok.
>>
>> (c) thread(s) for ResourceServlet hit the unlucky scenario where
>> the thread
>> still has a FacesContext left in it, and so ResourceServlet doesn't
>> create
>> one, but then a call later on in a class invoked by ResourceServlet
>> tries to
>> use the FacesContext & none exists
>>
>> The problem generally manifests much like the stacktrace below,
>> with a null
>> pointer resulting from there not being a valid faces context & the
>> resource
>> servlet not being able to determine the locale.
>>
>> at
>> weblogic.
>> servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:42)
>> at
>> weblogic.
>> servlet.
>> internal.RequestEventsFilter.doFilter(RequestEventsFilter.java:27)
>> at
>> weblogic.
>> servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:42)
>> at
>> weblogic.servlet.internal.WebAppServletContext
>> $ServletInvocationAction.run(WebAppServletContext.java:3496)
>> at
>> weblogic.
>> security.
>> acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
>> at weblogic.security.service.SecurityManager.runAs(Unknown Source)
>> at
>> weblogic.
>> servlet.
>> internal.
>> WebAppServletContext.securedExecute(WebAppServletContext.java:2180)
>> at
>> weblogic.
>> servlet.
>> internal.WebAppServletContext.execute(WebAppServletContext.java:2086)
>> at
>> weblogic.
>> servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1406)
>> at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
>> at weblogic.work.ExecuteThread.run(ExecuteThread.java:173)
>> Caused by: java.lang.ExceptionInInitializerError
>> at
>> org.
>> apache.
>> myfaces.
>> trinidadinternal.
>> resource.
>> CoreRenderKitResourceLoader.<init>(CoreRenderKitResourceLoader.java:
>> 55)
>> ... 59 more
>> Caused by: java.lang.NullPointerException
>> at
>> org.
>> apache.
>> myfaces.
>> trinidadinternal.
>> resource.
>> CoreRenderKitResourceLoader.
>> getLocale(CoreRenderKitResourceLoader.java:94)
>> at
>> org.
>> apache.
>> myfaces.
>> trinidadinternal.
>> resource.
>> CoreRenderKitResourceLoader.
>> getLocaleElementsURI(CoreRenderKitResourceLoader.java:80)
>> at
>> org.
>> apache.
>> myfaces.
>> trinidadinternal.
>> resource.
>> LocaleElementsResourceLoader.
>> <clinit>(LocaleElementsResourceLoader.java:113)
>> ... 60 more
>>
>> Without knowing the code very well i'm not sure of the best
>> solution (ours
>> is temporarily to force a default for the locale in the
>> ResourceLoaders),
>> but i did notice this isn't logged very well (i added extra logging
>> to get
>> this trace), and also that the Null ResourceLoaders (i.e. can't be
>> created/init'd) are cached - perhaps only good ResourceLoaders
>> should be
>> cached ?
>>
>> The issue seems more prevalent on multi-cpu/core machines, and is
>> highly
>> reproduceable on x86_64 linux, but on our other enviros - Solaris
>> Sparc &
>> windows we rarely see it.
>>
>> Any ideas/suggestions?
>>
>> thanks
>>
>> David
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
Re: Issue with ResourceServlet
Posted by Matthias Wessendorf <ma...@apache.org>.
Hi David,
you said you see the issues on you x86_64 linux box with your application.
My question is now, do you see that with the plain vanilla 1.2.10 demo
application too ?
Eventually I am also interested in the WLS version that you are using.
Can you also create a jira ticket, so that we can keep track of it ?
Thanks,
Matthias
On Thu, Mar 12, 2009 at 6:12 AM, David Birch <da...@gmail.com> wrote:
> Hi, we've been getting an intermittent error with Trinidad that i think i
> have traced to the logic for resource retrieval. From following the code of
> ResourceServlet i can see there is an expectation by some classes it calls
> (mostly ResourceLoader subclasses) of a FacesContext to exist, i can see
> there is code at the very start of the servlet that creates the FacesContext
> if one doesn't already exist, though i think there must be at least the
> following scenarios to consider;
>
> (a) thread(s) for ResourceServlet are completely different to the initial
> page creation thread, and thus a faces context is created & so subsequent
> gets on it are ok
>
> (b) thread(s) for ResourceServlet are executed with the same thread as for
> the initial page creation, and for whatever reason the FacesContext hasn't
> yet been fully cleaned up & is still attached & so access is ok.
>
> (c) thread(s) for ResourceServlet hit the unlucky scenario where the thread
> still has a FacesContext left in it, and so ResourceServlet doesn't create
> one, but then a call later on in a class invoked by ResourceServlet tries to
> use the FacesContext & none exists
>
> The problem generally manifests much like the stacktrace below, with a null
> pointer resulting from there not being a valid faces context & the resource
> servlet not being able to determine the locale.
>
> at
> weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:42)
> at
> weblogic.servlet.internal.RequestEventsFilter.doFilter(RequestEventsFilter.java:27)
> at
> weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:42)
> at
> weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3496)
> at
> weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
> at weblogic.security.service.SecurityManager.runAs(Unknown Source)
> at
> weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2180)
> at
> weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2086)
> at
> weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1406)
> at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
> at weblogic.work.ExecuteThread.run(ExecuteThread.java:173)
> Caused by: java.lang.ExceptionInInitializerError
> at
> org.apache.myfaces.trinidadinternal.resource.CoreRenderKitResourceLoader.<init>(CoreRenderKitResourceLoader.java:55)
> ... 59 more
> Caused by: java.lang.NullPointerException
> at
> org.apache.myfaces.trinidadinternal.resource.CoreRenderKitResourceLoader.getLocale(CoreRenderKitResourceLoader.java:94)
> at
> org.apache.myfaces.trinidadinternal.resource.CoreRenderKitResourceLoader.getLocaleElementsURI(CoreRenderKitResourceLoader.java:80)
> at
> org.apache.myfaces.trinidadinternal.resource.LocaleElementsResourceLoader.<clinit>(LocaleElementsResourceLoader.java:113)
> ... 60 more
>
> Without knowing the code very well i'm not sure of the best solution (ours
> is temporarily to force a default for the locale in the ResourceLoaders),
> but i did notice this isn't logged very well (i added extra logging to get
> this trace), and also that the Null ResourceLoaders (i.e. can't be
> created/init'd) are cached - perhaps only good ResourceLoaders should be
> cached ?
>
> The issue seems more prevalent on multi-cpu/core machines, and is highly
> reproduceable on x86_64 linux, but on our other enviros - Solaris Sparc &
> windows we rarely see it.
>
> Any ideas/suggestions?
>
> thanks
>
> David
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf