sounds fine for to set manually all context (thread local) manually before calling destroy methods
*Romain Manni-Bucau* *Twitter: @rmannibucau <https://twitter.com/rmannibucau>* *Blog: **http://rmannibucau.wordpress.com/*<http://rmannibucau.wordpress.com/> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/4/16 Thomas Andraschko <[email protected]> > The problem also occurs on cointainer shutdown. I think it was introduced > within: > https://issues.apache.org/jira/browse/OWB-734 > > A possible and dirty solution would be to set the current SessionContext > from SessionContextManager#destroyAllSessions to > WebContextsService#sessionContexts. > But this seems very hacky... > > Any idea how this can be fixed otherwise? > > > 2013/4/16 Romain Manni-Bucau <[email protected]> > >> well, for such a case, whatever the way the threadlocals get initialized >> it will work. It shouldn't be so common and perf shouldn't be a big issue >> anymore in this case. >> >> *Romain Manni-Bucau* >> *Twitter: @rmannibucau <https://twitter.com/rmannibucau>* >> *Blog: >> **http://rmannibucau.wordpress.com/*<http://rmannibucau.wordpress.com/> >> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* >> *Github: https://github.com/rmannibucau* >> >> >> >> 2013/4/16 Thomas Andraschko <[email protected]> >> >>> What exactly do you mean Romain? >>> We could also call WebContextService#startContext in >>> WebBeansConfigurationListener#sessionDestroyed. >>> But don't know if it's the best way. >>> >>> >>> 2013/4/16 Romain Manni-Bucau <[email protected]> >>> >>>> the timeout method can simply set/remove the threadlocals already in >>>> place >>>> >>>> *Romain Manni-Bucau* >>>> *Twitter: @rmannibucau <https://twitter.com/rmannibucau>* >>>> *Blog: >>>> **http://rmannibucau.wordpress.com/*<http://rmannibucau.wordpress.com/> >>>> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* >>>> *Github: https://github.com/rmannibucau* >>>> >>>> >>>> >>>> 2013/4/16 Thomas Andraschko <[email protected]> >>>> >>>>> Hmm, i think we must pass the HttpSession from >>>>> WebBeansConfigurationListener#sessionDestroyed to >>>>> WebContextsService#getSessionContext. >>>>> The current logic always gets the session from the request. This does >>>>> of course not work in this case. >>>>> Any idea to do this in a clean way and without ThreadLocal's or other >>>>> hacks? >>>>> >>>>> >>>>> 2013/4/16 Thomas Andraschko <[email protected]> >>>>> >>>>>> Issue created -> https://issues.apache.org/jira/browse/OWB-841 >>>>>> >>>>>> >>>>>> 2013/4/16 Thomas Andraschko <[email protected]> >>>>>> >>>>>>> Hey Mark, >>>>>>> >>>>>>> its not a exception, i just tracked the method calls :) >>>>>>> It's just the warning the i mentioned in the first mail. >>>>>>> >>>>>>> I will play a little bit and create a ticket. Maybe it's also >>>>>>> related to CODI, as i don't have a bean with @PreDestroy. >>>>>>> >>>>>>> >>>>>>> 2013/4/16 Mark Struberg <[email protected]> >>>>>>> >>>>>>>> yup thats right, there is something wrong. >>>>>>>> But there must be something special in your situation as I've never >>>>>>>> seen this in production yet. >>>>>>>> >>>>>>>> Can you please create a JIRA so we can track it? >>>>>>>> Please also add >>>>>>>> >>>>>>>> * which version of owb >>>>>>>> * which servlet container >>>>>>>> * some info whats going on in your thread >>>>>>>> >>>>>>>> > >>>>>>>> InjectionTargetProducer.preDestroy(InjectionTargetProducer.java:132) >>>>>>>> It seems that you have a @PreDestroy method which has a >>>>>>>> @SessionScoped bean as injection point. >>>>>>>> Can you please reduce your session timeout to 2 minutes and set a >>>>>>>> breakpoint to the place where the Exception gets thrown >>>>>>>> (WebContextsService.java:793)? And then you should be able to see which >>>>>>>> Bean did cause this problem if you go down call stack. >>>>>>>> >>>>>>>> And now some info about why I hacked the lazy session start: >>>>>>>> Initially we started the SessionContext for each and every request. >>>>>>>> But that means that we also did this for JSF Resource requests (png, >>>>>>>> css, >>>>>>>> etc) or other requests which simply don't need any session. To reduce >>>>>>>> the >>>>>>>> number of sessions we now only request one if a SessionScoped bean gets >>>>>>>> requested. >>>>>>>> >>>>>>>> This was especially hard in our case as we configured 1 node to >>>>>>>> only serve all the resources of our app (and all our other nodes only >>>>>>>> serve >>>>>>>> 'real' pages) - which was another nice speed bump ;) >>>>>>>> You can look at MyFaces / Jakob Korherrs staticresourcehandler if >>>>>>>> you have a performance intense app. >>>>>>>> >>>>>>>> LieGrue, >>>>>>>> strub >>>>>>>> >>>>>>>> >>>>>>>> ------------------------------ >>>>>>>> *From:* Thomas Andraschko <[email protected]> >>>>>>>> *To:* [email protected]; Mark Struberg < >>>>>>>> [email protected]> >>>>>>>> *Sent:* Tuesday, 16 April 2013, 9:00 >>>>>>>> *Subject:* Re: Could NOT lazily initialize session context because >>>>>>>> of null RequestContext >>>>>>>> >>>>>>>> Here is the stacktrace: >>>>>>>> >>>>>>>> at >>>>>>>> org.apache.webbeans.web.context.WebContextsService.lazyStartSessionContext(WebContextsService.java:793) >>>>>>>> at >>>>>>>> org.apache.webbeans.web.context.WebContextsService.getSessionContext(WebContextsService.java:708) >>>>>>>> at >>>>>>>> org.apache.webbeans.web.context.WebContextsService.getCurrentContext(WebContextsService.java:248) >>>>>>>> at >>>>>>>> org.apache.webbeans.context.ContextFactory.getStandardContext(ContextFactory.java:185) >>>>>>>> at >>>>>>>> org.apache.webbeans.container.BeanManagerImpl.getContext(BeanManagerImpl.java:307) >>>>>>>> at >>>>>>>> org.apache.webbeans.portable.creation.AbstractProducer.getCreationalContext(AbstractProducer.java:105) >>>>>>>> at >>>>>>>> org.apache.webbeans.portable.creation.InjectionTargetProducer.preDestroy(InjectionTargetProducer.java:132) >>>>>>>> at >>>>>>>> org.apache.webbeans.component.InjectionTargetWrapper.preDestroy(InjectionTargetWrapper.java:98) >>>>>>>> at >>>>>>>> org.apache.webbeans.component.AbstractOwbBean.destroy(AbstractOwbBean.java:251) >>>>>>>> at >>>>>>>> org.apache.webbeans.context.AbstractContext.destroyInstance(AbstractContext.java:205) >>>>>>>> at >>>>>>>> org.apache.webbeans.context.AbstractContext.destroy(AbstractContext.java:227) >>>>>>>> at >>>>>>>> org.apache.webbeans.web.context.SessionContextManager.destroySessionContextWithSessionId(SessionContextManager.java:84) >>>>>>>> at >>>>>>>> org.apache.webbeans.web.context.WebContextsService.destroySessionContext(WebContextsService.java:495) >>>>>>>> at >>>>>>>> org.apache.webbeans.web.context.WebContextsService.endContext(WebContextsService.java:216) >>>>>>>> at >>>>>>>> org.apache.webbeans.servlet.WebBeansConfigurationListener.sessionDestroyed(WebBeansConfigurationListener.java:197) >>>>>>>> at >>>>>>>> org.eclipse.jetty.server.session.AbstractSessionManager.removeSession(AbstractSessionManager.java:801) >>>>>>>> at >>>>>>>> org.eclipse.jetty.server.session.AbstractSession.timeout(AbstractSession.java:340) >>>>>>>> at >>>>>>>> org.eclipse.jetty.server.session.HashSessionManager.scavenge(HashSessionManager.java:320) >>>>>>>> at >>>>>>>> org.eclipse.jetty.server.session.HashSessionManager$2.run(HashSessionManager.java:282) >>>>>>>> at java.util.TimerThread.mainLoop(Timer.java:555) >>>>>>>> at java.util.TimerThread.run(Timer.java:505) >>>>>>>> >>>>>>>> It happens when the session expires. >>>>>>>> Any idea? IMO it should not try to lazy start a session if the >>>>>>>> session will be destroyed. >>>>>>>> >>>>>>>> >>>>>>>> 2013/4/12 Thomas Andraschko <[email protected]> >>>>>>>> >>>>>>>> Hi Mark, >>>>>>>> >>>>>>>> hmm, weird. I always get them at runtime. 7-8 times today. I only >>>>>>>> changed some pages and layout stuff and refreshed the page. >>>>>>>> Maybe it's because Jetty's change scanning. >>>>>>>> I will try it with Tomcat on Monday. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 2013/4/12 Mark Struberg <[email protected]> >>>>>>>> >>>>>>>> Hi Thomas, this sometimes happens at container startup if the >>>>>>>> container code invokes some SessionScoped event. But the Session is >>>>>>>> only >>>>>>>> available in a request of course. this should be in the code already >>>>>>>> since >>>>>>>> a long time (1.1.2 or so) >>>>>>>> >>>>>>>> LieGrue, >>>>>>>> strub >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ------------------------------ >>>>>>>> *From:* Thomas Andraschko <[email protected]> >>>>>>>> *To:* [email protected] >>>>>>>> *Sent:* Friday, April 12, 2013 4:40 PM >>>>>>>> *Subject:* Could NOT lazily initialize session context because of >>>>>>>> null RequestContext >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> i have many times this warning during development: >>>>>>>> >>>>>>>> WARNING: Could NOT lazily initialize session context because of >>>>>>>> null RequestContext >>>>>>>> >>>>>>>> Why does this occur and how can i avoid it? >>>>>>>> I never mentioned this error in my old application which runned >>>>>>>> perfectly with 1.1.6 (or 1.1.5, cant remember) >>>>>>>> >>>>>>>> Regards, >>>>>>>> Thomas >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
