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

Reply via email to