Re: [Resin-interest] Session timeout/Invalidation in clustered environment.
Scott Ferguson wrote: On Feb 7, 2008, at 12:20 PM, Robert Leland wrote: Scott Ferguson wrote: On Feb 7, 2008, at 8:51 AM, Robert Leland wrote: In a single machine clustered environment the 20 minute timeout works, but in a two machine cluster the session does not timeout until 30 minutes.. Actually, that should be normal. To reduce network traffic, the active times are only updated infrequently, and therefore the timeout is treated as a minimum that gets stretched. So you won't see the sessions closed at exactly the session timeout value, but some minutes later. We have had a live session after 25 minutes So in order to have a 95% chance that the session times out at 20 minutes we have to set a session-timeout to what 15 minutes ? That seems a little counter intuitive to the spec definition. Well, the spec is never going to specify that a session has a timeout of exactly 20 minutes, since that's impossible to implement. It does guarantee that the session will live for at least 20 minutes. In theory, we could add a session-update-window as a configuration parameter. I'm not sure I understand why that would be important to an application, though. That does seem like it would be a little used ability. Some businesses/goverments have security requirements such as Web application shall log out a user after XX minutes of inactivity. I don't know how much tolerance is allowable. At the present I am not about to try and duplicate this functionality at an application level. I am going to say it works with qualifications and see what happens. Personally, setting a screen saver on the machine would seem to prevent use of the application more effectively. Thanks, -- Scott I would have liked the answer better if it was its an issue that has been improved/fixed in the latest version of resin then I could have encouraged my client to buy new licenses :) ! -- Scott The only difference in the single vs. two machine resin.conf is: Single machine //Use caucho directly no ISAPI filer http server-id=app1 host=127.0.0.1 port=80 read-timeout=300s write-timeout=300s/ //One server in cluster srun server-id=app1 host=127.0.0.1 port=6802 index=1/ web-app-deploy path=webapps/ //Runs in development directory web-app id=/ document-directory=D:/Projects/IOP//code/web /web-app web-app id=/-help document-directory=webapps/-help /web-app Two machine Cluster (No front end load balancer) //Uses IIS via ISAPI as front end no direct access to resin configured. srun server-id=app1 host=web1 port=6802 index=1/ srun server-id=app2 host=web2 port=6802 index=2/ //Uses directory with war files web-app-deploy path=d:/web/apps/war-dir/ I couldn't tell if this issue might have been fixed my 3.1.4 or 3.0.25, we are currently using 3.0.23. Possibly related Issues that were fixed. security: update form-login with session timeout issue (#1674, rep by bthakkar) session saving was still attemped after invalidation (#2031, rep by jkriesten) timing issues with session invalidation (#1897, rep by Bradley Van Cleave) session: update invalidation to ensure invalidation drops session (#1951) -Rob *_ ** Robert Leland INTEGRITY One Partners * P: (703) 581-6522 1900 Campus Commons Drive, Suite 150 F: (703) 476-7405 Reston, VA 20191 [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] *BUSINESS CONSULTING | TECHNOLOGY | INNOVATION RD* ___ resin-interest mailing list resin-interest@caucho.com mailto: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 -- -Rob *_ ** Robert Leland INTEGRITY One Partners * P: (703) 581-6522 1900 Campus Commons Drive, Suite 150 F: (703) 476-7405 Reston, VA 20191 [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] *BUSINESS CONSULTING | TECHNOLOGY | INNOVATION RD* ___ resin-interest mailing list resin-interest@caucho.com mailto: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 -- -Rob *_ ** Robert Leland INTEGRITY One Partners * P: (703) 581-6522
Re: [Resin-interest] Session timeout/Invalidation in clustered environment.
Doesn't work under 3.0.25 Pro Evaluation copy(Thanks Ellen!): Changing app-default.xml web-app-default session-config use-persistent-store=true always-save-session=true session-timeout20/session-timeout /session-config ... web-app-default The session still doesn't timeout after 20 minutes on a 2 server cluster. Robert Leland wrote: In my web.xml I have ?xml version=1.0 encoding=ISO-8859-1? web-app xmlns=http://java.sun.com/xml/ns/j2ee; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd; version=2.4 display-nameXXX/display-name session-config session-timeout20/session-timeout /session-config ... /web-app In a single machine clustered environment the 20 minute timeout works, but in a two machine cluster the session does not timeout until 30 minutes.. The only difference in the single vs. two machine resin.conf is: Single machine //Use caucho directly no ISAPI filer http server-id=app1 host=127.0.0.1 port=80 read-timeout=300s write-timeout=300s/ //One server in cluster srun server-id=app1 host=127.0.0.1 port=6802 index=1/ web-app-deploy path=webapps/ //Runs in development directory web-app id=/ document-directory=D:/Projects/IOP//code/web /web-app web-app id=/-help document-directory=webapps/-help /web-app Two machine Cluster (No front end load balancer) //Uses IIS via ISAPI as front end no direct access to resin configured. srun server-id=app1 host=web1 port=6802 index=1/ srun server-id=app2 host=web2 port=6802 index=2/ //Uses directory with war files web-app-deploy path=d:/web/apps/war-dir/ I couldn't tell if this issue might have been fixed my 3.1.4 or 3.0.25, we are currently using 3.0.23. Possibly related Issues that were fixed. security: update form-login with session timeout issue (#1674, rep by bthakkar) session saving was still attemped after invalidation (#2031, rep by jkriesten) timing issues with session invalidation (#1897, rep by Bradley Van Cleave) session: update invalidation to ensure invalidation drops session (#1951) -Rob *_ ** Robert Leland INTEGRITY One Partners * P: (703) 581-6522 1900 Campus Commons Drive, Suite 150 F: (703) 476-7405 Reston, VA 20191 [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] *BUSINESS CONSULTING | TECHNOLOGY | INNOVATION RD* ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest -- -Rob *_ ** Robert Leland INTEGRITY One Partners * P: (703) 581-6522 1900 Campus Commons Drive, Suite 150 F: (703) 476-7405 Reston, VA 20191 [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] *BUSINESS CONSULTING | TECHNOLOGY | INNOVATION RD* ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Session timeout/Invalidation in clustered environment.
On Feb 7, 2008, at 12:20 PM, Robert Leland wrote: Scott Ferguson wrote: On Feb 7, 2008, at 8:51 AM, Robert Leland wrote: In a single machine clustered environment the 20 minute timeout works, but in a two machine cluster the session does not timeout until 30 minutes.. Actually, that should be normal. To reduce network traffic, the active times are only updated infrequently, and therefore the timeout is treated as a minimum that gets stretched. So you won't see the sessions closed at exactly the session timeout value, but some minutes later. We have had a live session after 25 minutes So in order to have a 95% chance that the session times out at 20 minutes we have to set a session-timeout to what 15 minutes ? That seems a little counter intuitive to the spec definition. Well, the spec is never going to specify that a session has a timeout of exactly 20 minutes, since that's impossible to implement. It does guarantee that the session will live for at least 20 minutes. In theory, we could add a session-update-window as a configuration parameter. I'm not sure I understand why that would be important to an application, though. -- Scott I would have liked the answer better if it was its an issue that has been improved/fixed in the latest version of resin then I could have encouraged my client to buy new licenses :) ! -- Scott The only difference in the single vs. two machine resin.conf is: Single machine //Use caucho directly no ISAPI filer http server-id=app1 host=127.0.0.1 port=80 read- timeout=300s write-timeout=300s/ //One server in cluster srun server-id=app1 host=127.0.0.1 port=6802 index=1/ web-app-deploy path=webapps/ //Runs in development directory web-app id=/ document-directory=D:/Projects/IOP// code/web /web-app web-app id=/-help document-directory=webapps/- help /web-app Two machine Cluster (No front end load balancer) //Uses IIS via ISAPI as front end no direct access to resin configured. srun server-id=app1 host=web1 port=6802 index=1/ srun server-id=app2 host=web2 port=6802 index=2/ //Uses directory with war files web-app-deploy path=d:/web/apps/war-dir/ I couldn't tell if this issue might have been fixed my 3.1.4 or 3.0.25, we are currently using 3.0.23. Possibly related Issues that were fixed. security: update form-login with session timeout issue (#1674, rep by bthakkar) session saving was still attemped after invalidation (#2031, rep by jkriesten) timing issues with session invalidation (#1897, rep by Bradley Van Cleave) session: update invalidation to ensure invalidation drops session (#1951) -Rob _ Robert Leland INTEGRITY One Partners P: (703) 581-6522 1900 Campus Commons Drive, Suite 150 F: (703) 476-7405 Reston, VA 20191 [EMAIL PROTECTED] BUSINESS CONSULTING | TECHNOLOGY | INNOVATION RD ___ 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 -- -Rob _ Robert Leland INTEGRITY One Partners P: (703) 581-6522 1900 Campus Commons Drive, Suite 150 F: (703) 476-7405 Reston, VA 20191 [EMAIL PROTECTED] BUSINESS CONSULTING | TECHNOLOGY | INNOVATION RD ___ 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] Session timeout/Invalidation in clustered environment.
Scott Ferguson wrote: On Feb 7, 2008, at 8:51 AM, Robert Leland wrote: In a single machine clustered environment the 20 minute timeout works, but in a two machine cluster the session does not timeout until 30 minutes.. Actually, that should be normal. To reduce network traffic, the active times are only updated infrequently, and therefore the timeout is treated as a minimum that gets stretched. So you won't see the sessions closed at exactly the session timeout value, but some minutes later. We have had a live session after 25 minutes So in order to have a 95% chance that the session times out at 20 minutes we have to set a session-timeout to what 15 minutes ? That seems a little counter intuitive to the spec definition. I would have liked the answer better if it was its an issue that has been improved/fixed in the latest version of resin then I could have encouraged my client to buy new licenses :) ! -- Scott The only difference in the single vs. two machine resin.conf is: Single machine //Use caucho directly no ISAPI filer http server-id=app1 host=127.0.0.1 port=80 read-timeout=300s write-timeout=300s/ //One server in cluster srun server-id=app1 host=127.0.0.1 port=6802 index=1/ web-app-deploy path=webapps/ //Runs in development directory web-app id=/ document-directory=D:/Projects/IOP//code/web /web-app web-app id=/-help document-directory=webapps/-help /web-app Two machine Cluster (No front end load balancer) //Uses IIS via ISAPI as front end no direct access to resin configured. srun server-id=app1 host=web1 port=6802 index=1/ srun server-id=app2 host=web2 port=6802 index=2/ //Uses directory with war files web-app-deploy path=d:/web/apps/war-dir/ I couldn't tell if this issue might have been fixed my 3.1.4 or 3.0.25, we are currently using 3.0.23. Possibly related Issues that were fixed. security: update form-login with session timeout issue (#1674, rep by bthakkar) session saving was still attemped after invalidation (#2031, rep by jkriesten) timing issues with session invalidation (#1897, rep by Bradley Van Cleave) session: update invalidation to ensure invalidation drops session (#1951) -Rob *_ ** Robert Leland INTEGRITY One Partners * P: (703) 581-6522 1900 Campus Commons Drive, Suite 150 F: (703) 476-7405 Reston, VA 20191 [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] *BUSINESS CONSULTING | TECHNOLOGY | INNOVATION RD* ___ resin-interest mailing list resin-interest@caucho.com mailto: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 -- -Rob *_ ** Robert Leland INTEGRITY One Partners * P: (703) 581-6522 1900 Campus Commons Drive, Suite 150 F: (703) 476-7405 Reston, VA 20191 [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] *BUSINESS CONSULTING | TECHNOLOGY | INNOVATION RD* ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest