have you done tests like sending a backtrace to the session just to see if it is hung somewhere?
I recall finding sessions getting stuck on a poorly written ec threading issue that only came up once in a blue moon it seemed. once I saw a backtrace, it was quite obvious where the trouble was. On Jan 12, 2013, at 12:43 PM, Matteo Centro <[email protected]> wrote: > Sorry to resuscitate such an old discussion but I'm having the exact > same issue... > It's an old application that we "inherited", we wonderized it as much > as it's possible but something weird happens in production, sessions > on some instances simply won't die. > Some instances go out of memory and they hang there. > I'm in trouble and I needs some hints, both to fix the issue > temporarily and to fix it for good (of course in that case I assume > I'll have to rewrite the app, if only I could find the budget). > What are the most common causes of sessions not dying? > > Thanks, > > > Matteo > > On Thu, Aug 21, 2008 at 5:35 AM, Joe Little <[email protected]> wrote: >> I had something similar with sessions going bonkers on a public WO >> page that our internal google search engine completely trashed. In the >> end, robots.txt and explicit rules to deny certain patterns were added >> to prevent this. >> >> >> On Wed, Aug 20, 2008 at 8:17 PM, D Tim Cummings <[email protected]> wrote: >>> We have a couple of sessionless apps that have started showing this problem >>> with sessions that don't terminate. It turned out the sessions were being >>> created by malformed urls coming from malicious robot web crawlers. The >>> urls were of the form >>> http://www.courses.qut.edu.au/cgi-bin/WebObjects/Courses.woa/wa/cgi-bin/WebObjects/Courses.woa >>> Maybe see if you are getting incorrect links to your sessionless login page. >>> We solved the problem by catching unknown direct actions in >>> DirectAction.java >>> @Override >>> public WOActionResults performActionNamed(String actionName) { >>> try { >>> return super.performActionNamed(actionName); >>> } catch (NSForwardException nsfe) { >>> log.info("ns forward exception - prbalby no such method for " + actionName); >>> } >>> return defaultAction(); >>> } >>> and in Application.java directing exceptions back to the Main page (for URLs >>> with more than one / after wa). >>> @Override >>> public WOComponent pageWithName(String namePage, WOContext context) { >>> if ( "WOExceptionPage".equals(namePage) ) { >>> namePage = "Main"; >>> } >>> if ( "WOSessionRestorationError".equals(namePage) ) { >>> namePage = "Main"; >>> } >>> return super.pageWithName(namePage, context); >>> } >>> >>> and in Main.java >>> public void setException ( Exception e ) { >>> log.error("an exception occurred " + e); >>> } >>> >>> We are running apps with embedded Wonder 4 and WebObjects 5.3.3 on Mac OS X >>> Server 10.5.4 with WebObjects 5.4.2 deployment. We didn't have the problem >>> before we went to this setup, but maybe we weren't getting hit with the same >>> url format then. >>> Tim >>> On 21/08/2008, at 4:02 AM, Chuck Hill wrote: >>> >>> On Aug 20, 2008, at 9:54 AM, Simon McLean wrote: >>> >>> Hi All - >>> Wondering if someone can throw me some ideas on solving what looks like an >>> immortal session problem. >>> - Start up 1 instance in java monitor. >>> - User lands on sessionless login page. No sessions. >>> - User logs in. 1 session. >>> - User logs out. 0 sessions. >>> - User logs in. 1 session. >>> - User does nothing. Session times out. 0 sessions. >>> All looks good. However, we get to the end of the day and the instance has >>> 376 active sessions. But I know for this particular app there are only 6 >>> users, because they are all sitting next door :-) Also, If i now leave this >>> instance overnight none of those active sessions will go away. >>> So what could be going on ? Something appears to be creating immortal >>> sessions, but forced session termination (by the user logging out) and >>> session expiration seem to be behaving themselves. >>> >>> If the users don't notice any problems, my money would be on an exception >>> thrown from your Session.terminate(). Also check the sleep() method to >>> ensure it can never throw. >>> I have seen a related problem where two requests come in for the same >>> session (user double clicks, Ajax etc), and the first calls terminate() on >>> the session. The second thread is stuck and the app can't gracefully shut >>> down. IIRC, you would see zero sessions in this case. The "fix" for this >>> is to not call terminate() and instead set the session timeout to a small >>> number of seconds. >>> Chuck >>> -- >>> Chuck Hill Senior Consultant / VP Development >>> Practical WebObjects - for developers who want to increase their overall >>> knowledge of WebObjects or who are trying to solve specific problems. >>> http://www.global-village.net/products/practical_webobjects >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Do not post admin requests to the list. They will be ignored. >>> Webobjects-dev mailing list ([email protected]) >>> Help/Unsubscribe/Update your Subscription: >>> http://lists.apple.com/mailman/options/webobjects-dev/timcu%40tpg.com.au >>> This email sent to [email protected] >>> >>> >>> >>> _______________________________________________ >>> Do not post admin requests to the list. They will be ignored. >>> Webobjects-dev mailing list ([email protected]) >>> Help/Unsubscribe/Update your Subscription: >>> http://lists.apple.com/mailman/options/webobjects-dev/jmlittle%40gmail.com >>> >>> This email sent to [email protected] >>> >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Webobjects-dev mailing list ([email protected]) >> Help/Unsubscribe/Update your Subscription: >> http://lists.apple.com/mailman/options/webobjects-dev/wolists%40matteocentro.it >> >> This email sent to [email protected] > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list ([email protected]) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/webobjects-dev/jtayler%40oeinc.com > > This email sent to [email protected] _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
