Re: Immortal sessions in production
Re: Immortal sessions in production
- Subject: Re: Immortal sessions in production
- From: Matteo Centro <email@hidden>
- Date: Sat, 12 Jan 2013 23:01:44 +0100
Thanks, I'll try that.
Anyway (I can't say it's that but this happens often in instances with
immortal sessions):
I get this in my terminate() method
java.lang.IllegalMonitorStateException
at java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(ReentrantLock.java:127)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.release(AbstractQueuedSynchronizer.java:1239)
at java.util.concurrent.locks.ReentrantLock.unlock(ReentrantLock.java:431)
at com.webobjects.eocontrol.EOObjectStoreCoordinator.unlock(EOObjectStoreCoordinator.java:460)
at com.webobjects.eocontrol.EOEditingContext.unlockObjectStore(EOEditingContext.java:4684)
at er.extensions.eof.ERXEC.unlockObjectStore(ERXEC.java:805)
at com.webobjects.eocontrol.EOCustomObject.willReadRelationship(EOCustomObject.java:1281)
at er.extensions.eof.ERXGenericRecord.willReadRelationship(ERXGenericRecord.java:378)
at com.webobjects.eocontrol._EOMutableKnownKeyDictionary$Initializer$_LazyGenericRecordBinding.valueInObject(_EOMutableKnownKeyDictionary.java:614)
at com.webobjects.eocontrol.EOCustomObject.storedValueForKey(EOCustomObject.java:1634)
I'm using ERXEC everywhere and I'm not locking explicitly, should I
lock the ec in the terminate method?
Matteo
On Sat, Jan 12, 2013 at 8:39 PM, Simon <email@hidden> wrote:
> 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