You are viewing a plain text version of this content. The canonical link for it is here.

Posted to user@openwebbeans.apache.org by Thomas Andraschko <an...@gmail.com> on 2013/04/12 16:40:25 UTC

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

Re: Could NOT lazily initialize session context because of null RequestContext

Posted by Romain Manni-Bucau <rm...@gmail.com>.

can't we get it? maybe we should just change the lazy strategy

for me that's really a warning

*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 <an...@gmail.com>

> Shoudln't we change the log level then? Warning is a little bit high for a
> case which occurs always for every session.
>
>
> 2013/4/16 Romain Manni-Bucau <rm...@gmail.com>
>
>> If the session expires it should be able to get it and it is mandatory to
>> cleanup beans which could have been put in a forgotten session (mainly
>> @SessionScoped, @ConversationScoped)
>>
>> *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 <an...@gmail.com>
>>
>>> 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 <an...@gmail.com>
>>>
>>>> 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 <st...@yahoo.de>
>>>>
>>>>> 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 <an...@gmail.com>
>>>>> *To:* user@openwebbeans.apache.org
>>>>> *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
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>

Re: Could NOT lazily initialize session context because of null RequestContext

Posted by Thomas Andraschko <an...@gmail.com>.

Shoudln't we change the log level then? Warning is a little bit high for a
case which occurs always for every session.


2013/4/16 Romain Manni-Bucau <rm...@gmail.com>

> If the session expires it should be able to get it and it is mandatory to
> cleanup beans which could have been put in a forgotten session (mainly
> @SessionScoped, @ConversationScoped)
>
> *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 <an...@gmail.com>
>
>> 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 <an...@gmail.com>
>>
>>> 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 <st...@yahoo.de>
>>>
>>>> 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 <an...@gmail.com>
>>>> *To:* user@openwebbeans.apache.org
>>>> *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
>>>>
>>>>
>>>>
>>>
>>
>

Re: Could NOT lazily initialize session context because of null RequestContext

Posted by Romain Manni-Bucau <rm...@gmail.com>.

If the session expires it should be able to get it and it is mandatory to
cleanup beans which could have been put in a forgotten session (mainly
@SessionScoped, @ConversationScoped)

*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 <an...@gmail.com>

> 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 <an...@gmail.com>
>
>> 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 <st...@yahoo.de>
>>
>>> 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 <an...@gmail.com>
>>> *To:* user@openwebbeans.apache.org
>>> *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
>>>
>>>
>>>
>>
>

Re: Could NOT lazily initialize session context because of null RequestContext

Posted by Romain Manni-Bucau <rm...@gmail.com>.

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 <an...@gmail.com>

> 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 <rm...@gmail.com>
>
>> 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 <an...@gmail.com>
>>
>>> 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 <rm...@gmail.com>
>>>
>>>> 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 <an...@gmail.com>
>>>>
>>>>> 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 <an...@gmail.com>
>>>>>
>>>>>> Issue created -> https://issues.apache.org/jira/browse/OWB-841
>>>>>>
>>>>>>
>>>>>> 2013/4/16 Thomas Andraschko <an...@gmail.com>
>>>>>>
>>>>>>> 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 <st...@yahoo.de>
>>>>>>>
>>>>>>>> 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 <an...@gmail.com>
>>>>>>>> *To:* user@openwebbeans.apache.org; Mark Struberg <
>>>>>>>> struberg@yahoo.de>
>>>>>>>> *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 <an...@gmail.com>
>>>>>>>>
>>>>>>>> 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 <st...@yahoo.de>
>>>>>>>>
>>>>>>>> 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 <an...@gmail.com>
>>>>>>>> *To:* user@openwebbeans.apache.org
>>>>>>>> *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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Re: Could NOT lazily initialize session context because of null RequestContext

Posted by Thomas Andraschko <an...@gmail.com>.

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 <rm...@gmail.com>

> 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 <an...@gmail.com>
>
>> 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 <rm...@gmail.com>
>>
>>> 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 <an...@gmail.com>
>>>
>>>> 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 <an...@gmail.com>
>>>>
>>>>> Issue created -> https://issues.apache.org/jira/browse/OWB-841
>>>>>
>>>>>
>>>>> 2013/4/16 Thomas Andraschko <an...@gmail.com>
>>>>>
>>>>>> 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 <st...@yahoo.de>
>>>>>>
>>>>>>> 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 <an...@gmail.com>
>>>>>>> *To:* user@openwebbeans.apache.org; Mark Struberg <st...@yahoo.de>
>>>>>>>
>>>>>>> *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 <an...@gmail.com>
>>>>>>>
>>>>>>> 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 <st...@yahoo.de>
>>>>>>>
>>>>>>> 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 <an...@gmail.com>
>>>>>>> *To:* user@openwebbeans.apache.org
>>>>>>> *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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Re: Could NOT lazily initialize session context because of null RequestContext

Posted by Romain Manni-Bucau <rm...@gmail.com>.

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 <an...@gmail.com>

> 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 <rm...@gmail.com>
>
>> 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 <an...@gmail.com>
>>
>>> 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 <an...@gmail.com>
>>>
>>>> Issue created -> https://issues.apache.org/jira/browse/OWB-841
>>>>
>>>>
>>>> 2013/4/16 Thomas Andraschko <an...@gmail.com>
>>>>
>>>>> 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 <st...@yahoo.de>
>>>>>
>>>>>> 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 <an...@gmail.com>
>>>>>> *To:* user@openwebbeans.apache.org; Mark Struberg <st...@yahoo.de>
>>>>>>
>>>>>> *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 <an...@gmail.com>
>>>>>>
>>>>>> 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 <st...@yahoo.de>
>>>>>>
>>>>>> 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 <an...@gmail.com>
>>>>>> *To:* user@openwebbeans.apache.org
>>>>>> *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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Re: Could NOT lazily initialize session context because of null RequestContext

Posted by Thomas Andraschko <an...@gmail.com>.

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 <rm...@gmail.com>

> 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 <an...@gmail.com>
>
>> 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 <an...@gmail.com>
>>
>>> Issue created -> https://issues.apache.org/jira/browse/OWB-841
>>>
>>>
>>> 2013/4/16 Thomas Andraschko <an...@gmail.com>
>>>
>>>> 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 <st...@yahoo.de>
>>>>
>>>>> 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 <an...@gmail.com>
>>>>> *To:* user@openwebbeans.apache.org; Mark Struberg <st...@yahoo.de>
>>>>> *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 <an...@gmail.com>
>>>>>
>>>>> 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 <st...@yahoo.de>
>>>>>
>>>>> 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 <an...@gmail.com>
>>>>> *To:* user@openwebbeans.apache.org
>>>>> *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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>

Re: Could NOT lazily initialize session context because of null RequestContext

Posted by Romain Manni-Bucau <rm...@gmail.com>.

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 <an...@gmail.com>

> 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 <an...@gmail.com>
>
>> Issue created -> https://issues.apache.org/jira/browse/OWB-841
>>
>>
>> 2013/4/16 Thomas Andraschko <an...@gmail.com>
>>
>>> 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 <st...@yahoo.de>
>>>
>>>> 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 <an...@gmail.com>
>>>> *To:* user@openwebbeans.apache.org; Mark Struberg <st...@yahoo.de>
>>>> *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 <an...@gmail.com>
>>>>
>>>> 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 <st...@yahoo.de>
>>>>
>>>> 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 <an...@gmail.com>
>>>> *To:* user@openwebbeans.apache.org
>>>> *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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>

Re: Could NOT lazily initialize session context because of null RequestContext

Posted by Thomas Andraschko <an...@gmail.com>.

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 <an...@gmail.com>

> Issue created -> https://issues.apache.org/jira/browse/OWB-841
>
>
> 2013/4/16 Thomas Andraschko <an...@gmail.com>
>
>> 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 <st...@yahoo.de>
>>
>>> 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 <an...@gmail.com>
>>> *To:* user@openwebbeans.apache.org; Mark Struberg <st...@yahoo.de>
>>> *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 <an...@gmail.com>
>>>
>>> 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 <st...@yahoo.de>
>>>
>>> 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 <an...@gmail.com>
>>> *To:* user@openwebbeans.apache.org
>>> *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
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>

Re: Could NOT lazily initialize session context because of null RequestContext

Posted by Thomas Andraschko <an...@gmail.com>.

Issue created -> https://issues.apache.org/jira/browse/OWB-841


2013/4/16 Thomas Andraschko <an...@gmail.com>

> 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 <st...@yahoo.de>
>
>> 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 <an...@gmail.com>
>> *To:* user@openwebbeans.apache.org; Mark Struberg <st...@yahoo.de>
>> *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 <an...@gmail.com>
>>
>> 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 <st...@yahoo.de>
>>
>> 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 <an...@gmail.com>
>> *To:* user@openwebbeans.apache.org
>> *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
>>
>>
>>
>>
>>
>>
>>
>

Re: Could NOT lazily initialize session context because of null RequestContext

Posted by Thomas Andraschko <an...@gmail.com>.

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 <st...@yahoo.de>

> 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 <an...@gmail.com>
> *To:* user@openwebbeans.apache.org; Mark Struberg <st...@yahoo.de>
> *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 <an...@gmail.com>
>
> 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 <st...@yahoo.de>
>
> 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 <an...@gmail.com>
> *To:* user@openwebbeans.apache.org
> *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
>
>
>
>
>
>
>

Re: Could NOT lazily initialize session context because of null RequestContext

Posted by Mark Struberg <st...@yahoo.de>.

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 <an...@gmail.com>
>To: user@openwebbeans.apache.org; Mark Struberg <st...@yahoo.de> 
>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 <an...@gmail.com>
>
>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 <st...@yahoo.de>
>>
>>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 <an...@gmail.com>
>>>>To: user@openwebbeans.apache.org 
>>>>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
>>>>
>>>>
>>>>
>>
>
>
>

Re: Could NOT lazily initialize session context because of null RequestContext

Posted by Thomas Andraschko <an...@gmail.com>.

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 <an...@gmail.com>

> 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 <st...@yahoo.de>
>
>> 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 <an...@gmail.com>
>> *To:* user@openwebbeans.apache.org
>> *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
>>
>>
>>
>

Re: Could NOT lazily initialize session context because of null RequestContext

Posted by Thomas Andraschko <an...@gmail.com>.

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 <st...@yahoo.de>

> 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 <an...@gmail.com>
> *To:* user@openwebbeans.apache.org
> *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
>
>
>

Re: Could NOT lazily initialize session context because of null RequestContext

Posted by Mark Struberg <st...@yahoo.de>.

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 <an...@gmail.com>
>To: user@openwebbeans.apache.org 
>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
>
>
>