Hi Eric When I hit a my logout servlet I forward the request to a page which will redirect to a protected page - forcing a login screen to be shown. Occasionally, when I logout I will go through this process and find myself still authenticated when I hit the protected resource, thus being logged in still.
I upgraded from Resin 3.0.26. I find it happens even with a low number of sessions. I'm experimenting with using the cluster session config instead. Before, I was forced to use JDBC sessions due to issues with scaling. I also see a difference in the number of sessions reported by each Resin node and the number in the database. Incidentally, as recommended I was using MySQL for the session database before moving it over to SQL Server 2005 (as with our application database). Before the upgrade to Resin 3.1 I experienced issues with sessions not invalidating properly far more frequently with MySQL than SQL Server. rgds, Richard -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Kreiser Sent: 07 October 2008 16:33 To: General Discussion for the Resin application server Subject: Re: [Resin-interest] HttpSession.invalidate() doesn't what are you seeing happen? what resin version did you upgrade from? I am looking at an issue currently where I have thousands of SessionImpl instances that seem like they should be GCed but are not. I am running resin pro 3.1.6 and just moved to resin pro 3.1.7a to see if I still have the same problem. I am using db persisted sessions, so I am see the number of sessions in the db verses the number of sessions reported by resin using jmx. Richard Grantham wrote: Hi list, I recently upgraded to Resin Professional 3.1.7a in the hope that the issues I had would be solved. For the most part they are, however, there are occasions when session.invalidate() still doesn't quite work and you have to logout twice. My resin-web.xml session configuration looks like this: <session-config use-persistent-store="true" reuse-session-id="false" invalidate-after-listener="true" cookie-secure="true" enable-url-rewriting="false" /> Is there anything else, configuration wise, that I may have missed that could be causing this issue? rgds, Richard -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Richard Grantham Sent: 23 June 2008 14:48 To: General Discussion for the Resin application server Subject: Re: [Resin-interest] HttpSession.invalidate() doesn't I've found that this could well be the cause of another related issue which has been causing me misery for the last few months. My 403.jsp has an element on it which is the result of a Web service call called via a tag. The call is made only if a person of the correct type is logged in as the call is protected by J2EE security. If nobody is logged in then a login box is displayed. When the Web service is called it is always done to the same server as displaying the 403 page. There have been several occasions when the JSP will display the 403 page and make the Web service call which will return a 403 which will make the call which will return a 403, etc. etc. etc. until Resin maxes out its thread, hangs and needs to be restarted. To my mind this would only happen if the wrong session was being pulled up with the call to request.getSession() in my tag. Any pointers as how to debug and solve this would be very much appreciated. For now I have removed the page element. rgds, Richard -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Richard Grantham Sent: 18 June 2008 12:47 To: General Discussion for the Resin application server Subject: Re: [Resin-interest] HttpSession.invalidate() doesn't I upgraded to Resin 3.0.26 and while the problem has certainly eased in frequency it has not disappeared. I have taken out the <always-save /> element. This wouldn't effect things would it? rgds, Richard Richard Grantham Development ------------------------------- [EMAIL PROTECTED] Limehouse Software Ltd DDI: (020) 7566 3336 Main: (020) 7566 3320 Fax: (020) 7566 3321 Limehouse Software Ltd 4th Floor 1 London Bridge London SE1 9BG Manchester Office: 3rd Floor, The Triangle, Exchange Square, Manchester M4 3TR Tel: (0161) 240 2440, Fax: (0161) 240 2441, ISDN: 08700 119 400 Check out Limehouse Software's innovative solutions www.limehousesoftware.co.uk - Transforming the way you publish and consult on information The information contained in this e-mail or in any attachments is confidential and is intended solely for the named addressee only. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Limehouse Software Ltd immediately by returning this e-mail to sender or calling 020 7566 3320 and do not read, use or disseminate the information. Opinions expressed in this e-mail are those of the sender and not necessarily the company. Although an active anti-virus policy is operated, the company accepts no liability for any damage caused by any virus transmitted by this e-mail, including any attachments.-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sam Sent: 17 June 2008 14:17 To: General Discussion for the Resin application server Subject: Re: [Resin-interest] HttpSession.invalidate() doesn't I'm using resin-pro-3.0.25 in a three-server cluster with session persistence configured using a MySQL database: <persistent-store type="jdbc"> <init> <data-source>jdbc/session</data-source> <always-load /> <always-save /> </init> </persistent-store> What I'm finding is that you can click logout up to 7 or 8 times before your session actually gets invalidated. The implementation of HttpSessionListener is doing its thing. The logout servlet is doing its thing but from what I can see the req.getSession().invalidate() call is NOT being respected. I believe that problem is addressed in 3.0.26, issue #2485 reported in the change log here: http://www.caucho.com/resin-3.0/features/changes.xtp PS. I am loath to switch (back) to using clustered sessions as I've had issues with random logouts and loads of timeout errors in the logs related to the internal Resin session store. There were a number if cluster store issues reported in the 3.1 branch, but the remaining issues in 3.0 have generally not been reported to us, we found them by doing increased stress testing for the 3.1 release. Take care, -- Sam _______________________________________________ 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 _______________________________________________ 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 -- Eric S. Kreiser Senior Software Architect Mzinga 5095 Ritter Road * Mechanicsburg, PA 17055 --------------------------------------------------- Call my office: 717.458.9804 Fax me: 717.790.0401 Email me: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> Learn more: http://mzinga.com/v/ekreiser/ <http://mzinga.com/v/ekreiser/> Toll Free: 800.869.5763 _______________________________________________ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
