Re: [Resin-interest] Session death in a cluster
On 11/19/2012 12:32 PM, Matthew Serrano wrote: 2. My database shows that some sessions seem to stay alive for days even though there is clearly no activity on the session. We have seen this behavior in resin for years. Several years ago, we wrote an administration utility for our Web site that displays the active HTTP sessions. We wrote this utility so we could see what products shoppers were putting in the carts. We noticed that some HTTP sessions live days after they should have been invalidated as a result of reaching the HTTP session timeout, which is set to 70 minutes. We never researched the problem or reported it to Caucho. We saw this behavior in resin 2.X, 3.X and now in 4.X Keith -- - Keith FettermanDirect: 206-319-9434 Mariner Supply, Inc. 206-780-5670 http://www.go2marine.com kfetter...@go2marine.com http://www.go2hydraulics.com http://www.shoprvparts.com ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Session death in a cluster
I have a web application that creates a session for every user who logs in and also tracks logins/logouts in a database. When the user logs out or when the session is destroyed (using a SessionListener), I attempt to update the database with the session destruction time. I experience two problems in a clustered environment: 1. Shutting down one resin node in the cluster seems to kill the session on that server even though the session is transferred to the other resin server and remains available. So, in effect, we think users are logged out when they are still active on the second server. 2. My database shows that some sessions seem to stay alive for days even though there is clearly no activity on the session. For the first issue, is there a way to write my session listener so that it knows the difference between a real session death and a transfer to another clustered instance due to a shutdown? For the second issue, I found an interesting attribute on the session-config tag (http://www.caucho.com/resin-4.0/admin/clustering-ref.xtp#sessionconfig): invalidate-after-listener: If true, invalidate the sessions after the session listeners have been called The documentation doesn't specify a default. Is it possible Resin is invalidating the session before my listener has a chance to inspect it, thus the listener can't update the database because the it doesn't know the user information? What is odd is that most of time the database is updated appropriately. Anybody else track user login behavior in a clustered environment? Going to be writing a message queue analytics system that could also track this but for now direct db is too simple to drop, especially when it works most of the time. thanks matt ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Session death in a cluster
As for #1, I have code in my SessionListener that first looks at the current thread and doesn't fire most of the work if it is the resin-destroy thread. This is a bit of a hack - anyone else find a cleaner way of handling this? thanks Eric On 11/19/2012 03:32 PM, Matthew Serrano wrote: I have a web application that creates a session for every user who logs in and also tracks logins/logouts in a database. When the user logs out or when the session is destroyed (using a SessionListener), I attempt to update the database with the session destruction time. I experience two problems in a clustered environment: 1. Shutting down one resin node in the cluster seems to kill the session on that server even though the session is transferred to the other resin server and remains available. So, in effect, we think users are logged out when they are still active on the second server. 2. My database shows that some sessions seem to stay alive for days even though there is clearly no activity on the session. For the first issue, is there a way to write my session listener so that it knows the difference between a real session death and a transfer to another clustered instance due to a shutdown? For the second issue, I found an interesting attribute on the session-config tag (http://www.caucho.com/resin-4.0/admin/clustering-ref.xtp#sessionconfig): invalidate-after-listener: If true, invalidate the sessions after the session listeners have been called The documentation doesn't specify a default. Is it possible Resin is invalidating the session before my listener has a chance to inspect it, thus the listener can't update the database because the it doesn't know the user information? What is odd is that most of time the database is updated appropriately. Anybody else track user login behavior in a clustered environment? Going to be writing a message queue analytics system that could also track this but for now direct db is too simple to drop, especially when it works most of the time. thanks matt ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
