Re: Immortal… ehm, frozen instances.
Re: Immortal… ehm, frozen instances.
- Subject: Re: Immortal… ehm, frozen instances.
- From: Altera WO Team <email@hidden>
- Date: Thu, 21 Mar 2013 19:00:40 +0100
On 21/mar/2013, at 15:25, George Domurot <email@hidden> wrote:
> I've seen this issue before, many years ago too. Where it bit me was where I touched sessions and contexts in my component without testing to see if I in fact had either to work with.
>
> You mentioned creating a context for your email. Are you then touching context.session()? It will lazy load a session. As will component.session().
No, we never touch session() in the e-mail component.
We create a context because we couldn't figure out how to instantiate a Component from outside the R-R loop, the mail component is only used to compose the e-mail….
>
> Search across your project for "session()" and "context()". There's typically a culprit out there.
>
> Here's a helper we use in our components for accessing a current session, but only if one already exists. It may be overkill, but at the time it helped remove our zombie sessions.
>
> public WOSession currentSession()
> {
> if (hasSession())
> {
> return session();
> }
> else if (context() != null)
> {
> if (context().hasSession())
> {
> return context().session();
> }
> else
> {
> return null;
> }
> }
> else
> {
> return null;
> }
> }
Thanks for that,
Matteo
>
> -George
> On Mar 21, 2013, at 6:47 AM, Altera WO Team <email@hidden> wrote:
>
>> I tried anyway and I can confirm. I'm not creating needless sessions.
>>
>> The app locks up anyway though…
>>
>> I lost hope in finding the real reason, for now I would be happy to find a dirty workaround. I need those apps to bounce anyway.
>>
>> I already tried using ERTimeToKill and it's ineffective.
>>
>> The lockups are quite rare: I have 10 instances running, bouncing every 6 hours and it happens maybe 2 times a week, but if an instance locks up the instances running become 9 and in the long run I'll have everything locked up.
>>
>> Any suggestions?
>>
>>
>> Matteo
>>
>>
>> On 20/mar/2013, at 01:16, Chuck Hill <email@hidden> wrote:
>>
>>> I think the problem is not that it is creating needless sessions, but that a checked-out session is not getting checked back in.
>>>
>>> Chuck
>>>
>>>
>>> On 2013-03-19, at 5:08 PM, Simon wrote:
>>>
>>>> if we have this kind of issue the first thing we do is log out session creation and check the stack traces. stick something like this in your session constructor then check the output:
>>>>
>>>> public Session() {
>>>> super();
>>>> StringWriter stringWriter = new StringWriter();
>>>>
>>>> PrintWriter printWriter = new PrintWriter(stringWriter);
>>>>
>>>> (new Throwable()).printStackTrace(printWriter);
>>>>
>>>> String trace = stringWriter.toString(); <---- log this somewhere that you can get easy access to
>>>>
>>>> }
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 19 March 2013 23:15, Altera WO Team <email@hidden> wrote:
>>>> Wow, good hint!
>>>>
>>>> In theory I'm not touching a Session but sometimes, when something in an EO changes I trigger e-mail sending.
>>>> I use ERMailDeliveryHTML using a component instantiated with a brand new wocontext using ERXWOContext.newContext()
>>>> the component is not referencing a Session in any part.
>>>>
>>>> Could it be the cause?
>>>>
>>>> Matteo
>>>>
>>>>
>>>> On 19/mar/2013, at 21:24, Simon <email@hidden> wrote:
>>>>
>>>>> ...or you are touching the session object outside the RR loop. the classic gotcha is rendering a component in a thread that touches the session in some way e.g. delivering an email in a thread that uses a component to render it's content... been caught by that one soooo many times!
>>>>>
>>>>>
>>>>> On 19 March 2013 17:51, Chuck Hill <email@hidden> wrote:
>>>>> Hi Matteo,
>>>>>
>>>>> You have one or more Zombie (aka Immortal) Sessions, as shown by stack traces like this:
>>>>> "WorkerThread11" prio=10 tid=0x0000000041848800 nid=0x1010 in Object.wait() [0x00007f16f7cfa000]
>>>>> java.lang.Thread.State: WAITING (on object monitor)
>>>>> at java.lang.Object.wait(Native Method)
>>>>> - waiting on <0x00000000d120b328> (a com.webobjects.appserver.WOSessionStore$TimeoutEntry)
>>>>> at java.lang.Object.wait(Object.java:485)
>>>>> at com.webobjects.appserver.WOSessionStore.checkOutSessionWithID(WOSessionStore.java:191)
>>>>> - locked <0x00000000d120b328> (a com.webobjects.appserver.WOSessionStore$TimeoutEntry)
>>>>> at com.webobjects.appserver.WOApplication.restoreSessionWithID(WOApplication.java:1913)
>>>>> at er.extensions.appserver.ERXApplication.restoreSessionWithID(ERXApplication.java:2403)
>>>>> at er.extensions.appserver.ERXWOContext.existingSession(ERXWOContext.java:57)
>>>>> at er.extensions.appserver.ERXWOContext.hasSession(ERXWOContext.java:69)
>>>>> at com.webobjects.appserver.WOAction.existingSession(WOAction.java:190)
>>>>> at com.tla.calendar.DirectAction.goToAction(DirectAction.java:454)
>>>>>
>>>>>
>>>>> This likely has one of two causes:
>>>>> 1. The application is getting OutOfMemory errors, which can leave the session store in an insane state
>>>>> 2. The app is throwing an exception from sleep() in Session. If you overrride sleep() it should use a try...finally block
>>>>>
>>>>> public void sleep() {
>>>>> try {
>>>>> // Your code here!
>>>>> } finally {
>>>>> super.sleep();
>>>>> }
>>>>> }
>>>>>
>>>>>
>>>>> Chuck
>>>>>
>>>>>
>>>>>
>>>>> On 2013-03-19, at 9:38 AM, Altera WO Team wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I'm having a strange issue on a WO installation on EC2 (oracle jvm).
>>>>>> Same strange application which had immortal sessions…
>>>>>>
>>>>>> Sometimes (quite rarely) a bounced application (put in refuse new sessions) never quits and it's not accessible from JavaMonitor.
>>>>>> If I look at the logs i see:
>>>>>>
>>>>>> Mar 19 12:38:52 B2C[2002] (ERXNSLogLog4jBridge.java:44) WARN NSLog - <com.tla.calendar.Application>: refusing new clients and below min active session threshold
>>>>>> Mar 19 12:38:52 B2C[2002] (ERXNSLogLog4jBridge.java:44) WARN NSLog - <com.tla.calendar.Application>: about to terminate...
>>>>>>
>>>>>> The only thing left is to kill the instance… Which is not nice.
>>>>>>
>>>>>> I'm not overriding the terminate() method in Application.
>>>>>>
>>>>>> I am attaching a stack trace if it helps.
>>>>>> <B2Cjstack.txt>
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>>
>>>>>>
>>>>>> Matteo Centro
>>>>>> _______________________________________________
>>>>>> 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
>>>>>
>>>>> --
>>>>> Chuck Hill
>>>>> Executive Managing Partner, VP Development and Technical Services
>>>>>
>>>>> 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/gvc/practical_webobjects
>>>>>
>>>>> Global Village Consulting ranks 13th in 2012 in BIV's Top 100 Fastest Growing Companies in B.C!
>>>>> Global Village Consulting ranks 76th in 24th annual PROFIT 200 ranking of Canada’s Fastest-Growing Companies by PROFIT Magazine!
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>>
>>>>
>>>>
>>>
>>> --
>>> Chuck Hill
>>> Executive Managing Partner, VP Development and Technical Services
>>>
>>> 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/gvc/practical_webobjects
>>>
>>> Global Village Consulting ranks 13th in 2012 in BIV's Top 100 Fastest Growing Companies in B.C!
>>> Global Village Consulting ranks 76th in 24th annual PROFIT 200 ranking of Canada’s Fastest-Growing Companies by PROFIT Magazine!
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> 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