Re: Immortal sessions in production
Re: Immortal sessions in production
- Subject: Re: Immortal sessions in production
- From: Simon <email@hidden>
- Date: Sat, 12 Jan 2013 19:39:21 +0000
stick this in your session constructor, it will log out whenever a
session is created. then you can start figuring out where you are
creating a session outside the RR loop which is the normal culprit...
StringWriter stringWriter = new StringWriter();
PrintWriter printWriter = new PrintWriter(stringWriter);
(new Throwable()).printStackTrace(printWriter);
String trace = stringWriter.toString();
log.debug("Session count = " + application().activeSessionsCount());
ClickEventLogger2.getLogger().fatal(ClickEventCode.E00129, "Session
Created:\n\n " + trace,
this.getClass().getSimpleName());
hmmm, you'll have to replace the "ClickEventLogger2" line because
that's our logging mechanism. you could log.fatal it and set up an
email appender in log4j.
simon
On 12 January 2013 17:43, Matteo Centro <email@hidden> 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@hidden> 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@hidden> 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@hidden)
>>> Help/Unsubscribe/Update your Subscription:
>>> This email sent to email@hidden
>>>
>>>
>>>
>>> _______________________________________________
>>> Do not post admin requests to the list. They will be ignored.
>>> Webobjects-dev mailing list (email@hidden)
>>> Help/Unsubscribe/Update your Subscription:
>>>
>>> This email sent to email@hidden
>>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Webobjects-dev mailing list (email@hidden)
>> Help/Unsubscribe/Update your Subscription:
>>
>> This email sent to email@hidden
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden