Re: Session invalidation and background thread
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 mgrigo...@apache.orgwrote: Hi, On Sat, Nov 23, 2013 at 2:11 PM, Marios Skounakis msc...@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 b...@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
Hi, On Sat, Nov 23, 2013 at 2:11 PM, Marios Skounakis msc...@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 b...@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
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
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 b...@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
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
