Re: Immortal sessions in production
Re: Immortal sessions in production
- Subject: Re: Immortal sessions in production
- From: Amedeo Mantica <email@hidden>
- Date: Sun, 13 Jan 2013 10:36:26 +0100
Are you sure the ec is only referenced by the session? Maybe there are objects referencing it outside the session. Application ? Any shared object ? A thread ?
Amedeo
Sent from my iPhone
On 12/gen/2013, at 23:01, Matteo Centro <email@hidden> wrote:
> 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
_______________________________________________
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