Re: [Resin-interest] Question on db based distributed session
Jacky, Whatever you quoted (in red) does not apply to your case, because in most of your situations, you did not have another Resin instance to be notified, as in it will notify the owner of the change At some point of step 2 and step 5, you did not even have any Resin instance running. But that does not mean this is not a problem. JDBC based session store should always contain the last known valid state, no matter which server was running. I noticed that your case has been filed into Resin bug http://bugs.caucho.com/view.php?id=1544 http://bugs.caucho.com/view.php?id=1544. . So, stop worrying. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jacky Sent: Monday, January 15, 2007 2:17 AM To: General Discussion for the Resin application server Subject: Re: [Resin-interest] Question on db based distributed session Eric? Sam? Warm regards, Jacky Wong Software Engineer Qinetics Solution Berhad Jacky wrote: Dear all, First of all, thanks for all the attentions. Greatly appreciated. Josh, - Please forgive me as i do not understand your have your cake and eat it too metaphor :S - I'm trying to implement the database backed distributed sessions as shown in http://www.caucho.com/resin-3.0/config/sessions.xtp and i dont take turn it off as a solution, at least not until i fully understand that this will not work. - You may be right with the clock of server A and server B not in sync, I'll have it checked.. Eric, - Yes, resin knows about my load balanced cluster (refer to the specific settings below) - I'm using apache with mod_caucho as the load balancer, is this inside or outside? :D - No, i'm not using always-load-session. I didnt' think that i need (but i'll give it a shot). Referring to http://www.caucho.com/resin-3.0/config/sessions.xtp, there is a paragraph stating this: For efficiency, the owning JVM keeps a cache of the session value, so it only needs to query the database when the session changes. If another JVM stores a new session value, it will notify the owner of the change so the owner can update its cache. Because of this notification, the database store is cluster-aware. my specific settings: #Apache snippet VirtualHost *:80 DocumentRoot /www/appA ServerName somedomain.com DirectoryIndex index.jsp ResinConfigServer 192.168.1.1 6802 ResinConfigServer 192.168.1.2 6802 CauchoStatus yes # do not remove, otherwise apache will serve the jsp source code once resin is down AddHandler caucho-request .jsp /VirtualHost # Resin snippet !-- Yes i'm aware that client-live-time and read-timeout is not supposed to be manually configured -- cluster client-live-time120s/client-live-time srun id=a host=192.168.1.1 port=6802 index=1 read-timeout=120s/ srun id=b host=192.168.1.2 port=6802 index=2 read-timeout=120s/ /cluster persistent-store type=jdbc init data-sourcejdbc/session/data-source /init /persistent-store host id=somedomain.com root-directory=/www/appA web-app id=/ document-directory=/www/appA session-config !-- 3 hour timeout -- session-timeout180/session-timeout use-persistent-store/ always-save-session/ /session-config servlet-mapping url-pattern=/servlet/* servlet-name=invoker/ /web-app /host Sam, I have 2 questions: Quote: At this point, A (the primary) will contact B to try to get any updates to the session that have been made. Since B is down, A cannot get the session from it. - Since i use always-save-session, shouldn't it try to get from B, but couldn't it get from the DB? Quote: So it has to go with the outdated session that it has, because it cannot get the updated session from B. - Please do correct me if i'm wrong, referring to this: If another JVM stores a new session value, it will notify the owner of the change so the owner can update its cache. Because of this notification, the database store is cluster-aware. - When B logs out my session, shouldn't it updates A's cache and the database at the same time? - Is it because i didn't use always-load-session ?? Gary Zhu, Quote: Even if server A and server B are configured to use the same database on server C, for a particular user session (say session id: abcDGs299928), server A and server B will have two different database entries of the session data, am I getting it right ? - I have thought of this as well when i look at the records in the table persistent_session of my mysql database. - But still... If another JVM stores a new session value, it will notify the owner of the change so the owner can update its cache. Because of this notification, the database store is cluster-aware. PS: Apache/2.0.55 Resin professional 3.0.19. Thanks all !! Warm regards, Jacky Wong Software Engineer Qinetics Solution Berhad
Re: [Resin-interest] Question on db based distributed session
Gary, thanks for the reply. Warm regards, Jacky Wong Software Engineer Qinetics Solution Berhad Gary Zhu wrote: Jacky, Whatever you quoted (in red) does not apply to your case, because in most of your situations, you did not have another Resin instance to be notified, as in "it will notify the owner of the change" At some point of step 2 and step 5, you did not even have any Resin instance running. But that does not mean this is not a problem. JDBC based session store should always contain the last known valid state, no matter which server was running. I noticed that your case has been filed into Resin bug http://bugs.caucho.com/view.php?id=1544. So, stop worrying. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jacky Sent: Monday, January 15, 2007 2:17 AM To: General Discussion for the Resin application server Subject: Re: [Resin-interest] Question on db based distributed session Eric? Sam? Warm regards, Jacky Wong Software Engineer Qinetics Solution Berhad Jacky wrote: Dear all, First of all, thanks for all the attentions. Greatly appreciated. Josh, - Please forgive me as i do not understand your "have your cake and eat it too" metaphor :S - I'm trying to implement the database backed distributed sessions as shown in http://www.caucho.com/resin-3.0/config/sessions.xtp and i dont take "turn it off" as a solution, at least not until i fully understand that this will not work. - You may be right with the clock of server A and server B not in sync, I'll have it checked.. Eric, - Yes, resin knows about my load balanced cluster (refer to the specific settings below) - I'm using apache with mod_caucho as the load balancer, is this inside or outside? :D - No, i'm not using always-load-session. I didnt' think that i need (but i'll give it a shot). Referring to http://www.caucho.com/resin-3.0/config/sessions.xtp, there is a paragraph stating this: "For efficiency, the owning JVM keeps a cache of the session value, so it only needs to query the database when the session changes. If another JVM stores a new session value, it will notify the owner of the change so the owner can update its cache. Because of this notification, the database store is cluster-aware." my specific settings: #Apache snippet VirtualHost *:80 DocumentRoot /www/appA ServerName somedomain.com DirectoryIndex index.jsp ResinConfigServer 192.168.1.1 6802 ResinConfigServer 192.168.1.2 6802 CauchoStatus yes # do not remove, otherwise apache will serve the jsp source code once resin is down AddHandler caucho-request .jsp /VirtualHost # Resin snippet !-- Yes i'm aware that client-live-time and read-timeout is not supposed to be manually configured -- cluster client-live-time120s/client-live-time srun id="a" host="192.168.1.1" port="6802" index="1" read-timeout="120s"/ srun id="b" host="192.168.1.2" port="6802" index="2" read-timeout="120s"/ /cluster persistent-store type="jdbc" init data-sourcejdbc/session/data-source /init /persistent-store host id="somedomain.com" root-directory="/www/appA" web-app id="/" document-directory="/www/appA" session-config !-- 3 hour timeout -- session-timeout180/session-timeout use-persistent-store/ always-save-session/ /session-config servlet-mapping url-pattern="/servlet/*" servlet-name="invoker"/ /web-app /host Sam, I have 2 questions: Quote: At this point, A (the primary) will contact B to try to get any updates to the session that have been made. Since B is down, A cannot get the session from it. - Since i use always-save-session, shouldn't it try to get from B, but couldn't it get from the DB? Quote: So it has to go with the outdated session that it has, because it cannot get the updated session from B. - Please do correct me if i'm wrong, referring to this: "If another JVM stores a new session value, it will notify the owner of the change so the owner can update its cache. Because of this notification, the database store is cluster-aware." - When B logs out my session, shouldn't it updates A's cache and the database at the same time? - Is it because i didn't use always-load-session ?? Gary Zhu, Quote: Even if server A and server B are configured to use the same database on server C, for a particular user session (say session id: abcDGs299928), server A and server B will have two different database entries of the session data, am I getting it right ? - I h
Re: [Resin-interest] Question on db based distributed session
Corrections below: On 1/8/07, Josh Rehman [EMAIL PROTECTED] wrote: ... While there are [[hacky]] ways to notify the offline server of state changes ... How can you have your cake and eat it too? You need some way for nodes to see if they are participating in a distributed session [[on startup]] and if they are and if there is an active node, ignore any persisted session state and get state from the distributed session. If there is no active node, then load session from disk. ... Peace, Josh ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Question on db based distributed session
what are your specific session settings? does resin know about your load balanced cluster? or are you managing the load balancer outside of resin and using resin to tie them together thru the db persistence? are you using 'always-load-session? Jacky wrote: Dear all, I have implemented resin's distributed session along with apache. Apache is the entry point, which will use mod_caucho plugin to dispatch requests to resin. Now it is working fine and i'm happy about it. After a few test run on this, i found out something which i'm not sure if its my implementation problem or bug. I have server A and server B running resin on default srun port 6802. Unhappy case 1: 1. I start server A and login to my application 2. I stop Server A and start Server B 3. I continue to work in the browser, my session stays intact and i can proceed normally 4. I stop Server B and start Server A 5. I continue to work in the browser, my session stays intact and i can proceed normally 6. I logout from my application and logout successfully cleared my session variables (notice this from app log) 7. I try to type a password protected page in the browser and i am forced to login 8. I stop Server A and start Server B 9. I try to type a password protected page in the browser and i *CAN ACCESS* the protected page Unhappy case 2: 1. I start server A and login to my application 2. I stop Server A and start Server B 3. I continue to work in the browser, my session stays intact and i can proceed normally 4. I logout from my application and logout successfully cleared my session variables (notice this from app log) 5. I stop Server B and start Server A 6. I try to type a password protected page in the browser and i *CAN ACCESS* the protected page So to sum it all up, if i login to Server A and try to log out in Server B, the session is still available to server A and not Server B. Does anyone here encounter this before? Thanks. -- Warm regards, Jacky Wong -- This message has been scanned for viruses and dangerous content by *MailScanner* http://www.mailscanner.info/, and is believed to be clean. ___ 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
Re: [Resin-interest] Question on db based distributed session
Hmm. I was reading: http://www.caucho.com/resin-3.1/doc/tcp-sessions.xtp Particularly the section under recovery which states: When Host C restarts, possibly with an upgraded version of Resin, it needs to use the most up-to-date version of the session; its file-saved session will probably be obsolete. When a new session arrives, Host C loads the saved session from both the file and from Host D. It will use the newest session as the current value. Once it's loaded the new session, it will remain consistent as if the server had never stopped. So Resin actually implements have your cake and eat it too but it's not working in your case. Perhaps there is some error when the comparison is made - perhaps the clocks on the two systems are not in sync. Or something. :) Peace, Josh On 1/8/07, Josh Rehman [EMAIL PROTECTED] wrote: Corrections below: On 1/8/07, Josh Rehman [EMAIL PROTECTED] wrote: ... While there are [[hacky]] ways to notify the offline server of state changes ... How can you have your cake and eat it too? You need some way for nodes to see if they are participating in a distributed session [[on startup]] and if they are and if there is an active node, ignore any persisted session state and get state from the distributed session. If there is no active node, then load session from disk. ... Peace, Josh ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Question on db based distributed session
1. I start server A and login to my application At this point, A will get your request and will become your primary server, and B will be your secondary server. 2. I stop Server A and start Server B 3. I continue to work in the browser, my session stays intact and i can proceed normally At this point, you are using secondary server B. Your session updates are saved on B. 4. I logout from my application and logout successfully cleared my session variables (notice this from app log) 5. I stop Server B and start Server A 6. I try to type a password protected page in the browser and i *CAN ACCESS* the protected page At this point, A (the primary) will contact B to try to get any updates to the session that have been made. Since B is down, A cannot get the session from it. So it has to go with the outdated session that it has, because it cannot get the updated session from B. -- Sam ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
