You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Marios Skounakis <ms...@gmail.com> on 2013/11/22 23:45:18 UTC
Session invalidation and background thread
Hi all,
This is maybe a Spring question but as my app is a wicket app and I use
this list regularly and everyone is very helpful I thought I'd ask here
first.
I have a RequestCycleListener which during onBeginRequest() conditionally
spawns some background threads and runs them using an Executor. These
threads need access to an oauth token which is stored in the session. So I
create my threads in the RequestCycleListener, give them a reference to the
wicket session and run them in the background thread. The threads also have
a reference to Spring's session (via spring's
RequestContextHolder.getRequestAttributes()/setRequestAttributes()).
Actually the dependence on spring session is much harder to alleviate as
they often need to access session scoped beans.
I'm wondering what exactly happens if I try to invalidate the session (e.g.
when the user logs out) while such a background thread is running. Is there
a possibility for harmful side-effects?
Should I consider adding code to my threads to periodically check that the
session is still valid? After all they do have a reference to the session
object, so this sounds feasible.
If it matters at all, I'm using Tomcat.
Thanks in advance,
Marios
Re: Session invalidation and background thread
Posted by Marios Skounakis <ms...@gmail.com>.
Martin,
I understand this is getting a bit off topic so we could as well drop it.
I understand that the threads and session will eventually be garbage
collected (go to /dev/null as you said). But this is not necessarily bad,
is it? In my case these threads are updating an application-wide cache. So
it is acceptable that they update the cache even if the session has been
unbound, and when they are done they may as well be gc'ed.
Am I missing something?
Thanks
Marios
On Sun, Nov 24, 2013 at 1:13 PM, Martin Grigorov <mg...@apache.org>wrote:
> Hi,
>
>
> On Sat, Nov 23, 2013 at 2:11 PM, Marios Skounakis <ms...@gmail.com>
> wrote:
>
> > Bas,
> >
> > Thanks for your answer. I understand what you're saying and you're right.
> > If I were designing the application now I'd do one of your suggestions.
> >
> > But unfortunately we've written most of the code and these threads now
> > depend on spring session beans. Right now B is pretty much the only
> viable
> > option. And we may go ahead and implement it (or maybe the polling
> > alternative).
> >
> > I'd like to repeat my question though, if only to gain some deeper
> > understanding of what's going on under the hood. Is there any danger if
> we
> > leave things as they are and we don't implement neither A nor B? What is
> > going to happen to the session? Will it still be invalidated, maybe
> causing
> > exceptions to the threads, or will it be kept around until the threads
> > finish? And once they all finish, will it be released or not?
> >
>
> What happens is that you will keep a reference to a plain object that is
> not managed by anything anymore.
> I.e. your case is a normal memory leak.
> Whatever you store in such session will go to /dev/null.
>
> I think you should consult with Servlet API -
>
> http://docs.oracle.com/javaee/6/api/javax/servlet/http/HttpSessionListener.html
> .
> This listener will inform you when a new session is bound and when one is
> destroyed. Your threads should work only with the currently active/live
> sessions.
>
>
> >
> > Cheers
> > Marios
> >
> >
> > On Sat, Nov 23, 2013 at 1:26 PM, Bas Gooren <ba...@iswd.nl> wrote:
> >
> > > Hi,
> > >
> > > I guess it depends on the lifecycle of those threads how I would handle
> > > this.
> > > Suppose the session is invalidated and destroyed, what should happen to
> > > the threads? Do they continue (A) or do they need to stop (B)?
> > >
> > > A) In this case I would not depend on the session at all, if possible.
> > > Simply copy the OAuth token to a private variable in your threads.
> > >
> > > B) Instead of the threads "polling" to see if the session is still
> there,
> > > I'd turn things around. Keep track of sessions-and-their-threads
> > somewhere.
> > > Register a session invalidation listener, and when the session is
> > > invalidated, you can run some code to neatly stop and clean up your
> > threads.
> > >
> > > Met vriendelijke groet,
> > > Kind regards,
> > >
> > > Bas Gooren
> > >
> > > schreef Marios Skounakis op 22-11-2013 23:45:
> > >
> > > Hi all,
> > >>
> > >> This is maybe a Spring question but as my app is a wicket app and I
> use
> > >> this list regularly and everyone is very helpful I thought I'd ask
> here
> > >> first.
> > >>
> > >> I have a RequestCycleListener which during onBeginRequest()
> > conditionally
> > >> spawns some background threads and runs them using an Executor. These
> > >> threads need access to an oauth token which is stored in the session.
> > So I
> > >> create my threads in the RequestCycleListener, give them a reference
> to
> > >> the
> > >> wicket session and run them in the background thread. The threads also
> > >> have
> > >> a reference to Spring's session (via spring's
> > >> RequestContextHolder.getRequestAttributes()/setRequestAttributes()).
> > >> Actually the dependence on spring session is much harder to alleviate
> as
> > >> they often need to access session scoped beans.
> > >>
> > >> I'm wondering what exactly happens if I try to invalidate the session
> > >> (e.g.
> > >> when the user logs out) while such a background thread is running. Is
> > >> there
> > >> a possibility for harmful side-effects?
> > >>
> > >> Should I consider adding code to my threads to periodically check that
> > the
> > >> session is still valid? After all they do have a reference to the
> > session
> > >> object, so this sounds feasible.
> > >>
> > >> If it matters at all, I'm using Tomcat.
> > >>
> > >> Thanks in advance,
> > >> Marios
> > >>
> > >>
> > >
> >
>
Re: Session invalidation and background thread
Posted by Martin Grigorov <mg...@apache.org>.
Hi,
On Sat, Nov 23, 2013 at 2:11 PM, Marios Skounakis <ms...@gmail.com> wrote:
> Bas,
>
> Thanks for your answer. I understand what you're saying and you're right.
> If I were designing the application now I'd do one of your suggestions.
>
> But unfortunately we've written most of the code and these threads now
> depend on spring session beans. Right now B is pretty much the only viable
> option. And we may go ahead and implement it (or maybe the polling
> alternative).
>
> I'd like to repeat my question though, if only to gain some deeper
> understanding of what's going on under the hood. Is there any danger if we
> leave things as they are and we don't implement neither A nor B? What is
> going to happen to the session? Will it still be invalidated, maybe causing
> exceptions to the threads, or will it be kept around until the threads
> finish? And once they all finish, will it be released or not?
>
What happens is that you will keep a reference to a plain object that is
not managed by anything anymore.
I.e. your case is a normal memory leak.
Whatever you store in such session will go to /dev/null.
I think you should consult with Servlet API -
http://docs.oracle.com/javaee/6/api/javax/servlet/http/HttpSessionListener.html
.
This listener will inform you when a new session is bound and when one is
destroyed. Your threads should work only with the currently active/live
sessions.
>
> Cheers
> Marios
>
>
> On Sat, Nov 23, 2013 at 1:26 PM, Bas Gooren <ba...@iswd.nl> wrote:
>
> > Hi,
> >
> > I guess it depends on the lifecycle of those threads how I would handle
> > this.
> > Suppose the session is invalidated and destroyed, what should happen to
> > the threads? Do they continue (A) or do they need to stop (B)?
> >
> > A) In this case I would not depend on the session at all, if possible.
> > Simply copy the OAuth token to a private variable in your threads.
> >
> > B) Instead of the threads "polling" to see if the session is still there,
> > I'd turn things around. Keep track of sessions-and-their-threads
> somewhere.
> > Register a session invalidation listener, and when the session is
> > invalidated, you can run some code to neatly stop and clean up your
> threads.
> >
> > Met vriendelijke groet,
> > Kind regards,
> >
> > Bas Gooren
> >
> > schreef Marios Skounakis op 22-11-2013 23:45:
> >
> > Hi all,
> >>
> >> This is maybe a Spring question but as my app is a wicket app and I use
> >> this list regularly and everyone is very helpful I thought I'd ask here
> >> first.
> >>
> >> I have a RequestCycleListener which during onBeginRequest()
> conditionally
> >> spawns some background threads and runs them using an Executor. These
> >> threads need access to an oauth token which is stored in the session.
> So I
> >> create my threads in the RequestCycleListener, give them a reference to
> >> the
> >> wicket session and run them in the background thread. The threads also
> >> have
> >> a reference to Spring's session (via spring's
> >> RequestContextHolder.getRequestAttributes()/setRequestAttributes()).
> >> Actually the dependence on spring session is much harder to alleviate as
> >> they often need to access session scoped beans.
> >>
> >> I'm wondering what exactly happens if I try to invalidate the session
> >> (e.g.
> >> when the user logs out) while such a background thread is running. Is
> >> there
> >> a possibility for harmful side-effects?
> >>
> >> Should I consider adding code to my threads to periodically check that
> the
> >> session is still valid? After all they do have a reference to the
> session
> >> object, so this sounds feasible.
> >>
> >> If it matters at all, I'm using Tomcat.
> >>
> >> Thanks in advance,
> >> Marios
> >>
> >>
> >
>
Re: Session invalidation and background thread
Posted by Marios Skounakis <ms...@gmail.com>.
Bas,
Thanks for your answer. I understand what you're saying and you're right.
If I were designing the application now I'd do one of your suggestions.
But unfortunately we've written most of the code and these threads now
depend on spring session beans. Right now B is pretty much the only viable
option. And we may go ahead and implement it (or maybe the polling
alternative).
I'd like to repeat my question though, if only to gain some deeper
understanding of what's going on under the hood. Is there any danger if we
leave things as they are and we don't implement neither A nor B? What is
going to happen to the session? Will it still be invalidated, maybe causing
exceptions to the threads, or will it be kept around until the threads
finish? And once they all finish, will it be released or not?
Cheers
Marios
On Sat, Nov 23, 2013 at 1:26 PM, Bas Gooren <ba...@iswd.nl> wrote:
> Hi,
>
> I guess it depends on the lifecycle of those threads how I would handle
> this.
> Suppose the session is invalidated and destroyed, what should happen to
> the threads? Do they continue (A) or do they need to stop (B)?
>
> A) In this case I would not depend on the session at all, if possible.
> Simply copy the OAuth token to a private variable in your threads.
>
> B) Instead of the threads "polling" to see if the session is still there,
> I'd turn things around. Keep track of sessions-and-their-threads somewhere.
> Register a session invalidation listener, and when the session is
> invalidated, you can run some code to neatly stop and clean up your threads.
>
> Met vriendelijke groet,
> Kind regards,
>
> Bas Gooren
>
> schreef Marios Skounakis op 22-11-2013 23:45:
>
> Hi all,
>>
>> This is maybe a Spring question but as my app is a wicket app and I use
>> this list regularly and everyone is very helpful I thought I'd ask here
>> first.
>>
>> I have a RequestCycleListener which during onBeginRequest() conditionally
>> spawns some background threads and runs them using an Executor. These
>> threads need access to an oauth token which is stored in the session. So I
>> create my threads in the RequestCycleListener, give them a reference to
>> the
>> wicket session and run them in the background thread. The threads also
>> have
>> a reference to Spring's session (via spring's
>> RequestContextHolder.getRequestAttributes()/setRequestAttributes()).
>> Actually the dependence on spring session is much harder to alleviate as
>> they often need to access session scoped beans.
>>
>> I'm wondering what exactly happens if I try to invalidate the session
>> (e.g.
>> when the user logs out) while such a background thread is running. Is
>> there
>> a possibility for harmful side-effects?
>>
>> Should I consider adding code to my threads to periodically check that the
>> session is still valid? After all they do have a reference to the session
>> object, so this sounds feasible.
>>
>> If it matters at all, I'm using Tomcat.
>>
>> Thanks in advance,
>> Marios
>>
>>
>
Re: Session invalidation and background thread
Posted by Bas Gooren <ba...@iswd.nl>.
Hi,
I guess it depends on the lifecycle of those threads how I would handle
this.
Suppose the session is invalidated and destroyed, what should happen to
the threads? Do they continue (A) or do they need to stop (B)?
A) In this case I would not depend on the session at all, if possible.
Simply copy the OAuth token to a private variable in your threads.
B) Instead of the threads "polling" to see if the session is still
there, I'd turn things around. Keep track of sessions-and-their-threads
somewhere. Register a session invalidation listener, and when the
session is invalidated, you can run some code to neatly stop and clean
up your threads.
Met vriendelijke groet,
Kind regards,
Bas Gooren
schreef Marios Skounakis op 22-11-2013 23:45:
> Hi all,
>
> This is maybe a Spring question but as my app is a wicket app and I use
> this list regularly and everyone is very helpful I thought I'd ask here
> first.
>
> I have a RequestCycleListener which during onBeginRequest() conditionally
> spawns some background threads and runs them using an Executor. These
> threads need access to an oauth token which is stored in the session. So I
> create my threads in the RequestCycleListener, give them a reference to the
> wicket session and run them in the background thread. The threads also have
> a reference to Spring's session (via spring's
> RequestContextHolder.getRequestAttributes()/setRequestAttributes()).
> Actually the dependence on spring session is much harder to alleviate as
> they often need to access session scoped beans.
>
> I'm wondering what exactly happens if I try to invalidate the session (e.g.
> when the user logs out) while such a background thread is running. Is there
> a possibility for harmful side-effects?
>
> Should I consider adding code to my threads to periodically check that the
> session is still valid? After all they do have a reference to the session
> object, so this sounds feasible.
>
> If it matters at all, I'm using Tomcat.
>
> Thanks in advance,
> Marios
>