Re: Immortal… ehm, frozen instances.
Re: Immortal… ehm, frozen instances.
- Subject: Re: Immortal… ehm, frozen instances.
- From: Chuck Hill <email@hidden>
- Date: Tue, 19 Mar 2013 11:24:07 -0700
Hi Matteo,
I would use the same try...finally block in terminate() as well. And a finally inside of that to unlock the ec.
Chuck
On 2013-03-19, at 11:20 AM, Altera WO Team wrote:
> Thanks Chuck,
>
> no OutOfMemory errors (at least in the log)
> and no override of sleep()
>
> but we do override terminate()
>
> @Override
> public void terminate() {
try {
> log.info("TERMINATE " + sessionID());
>
> ec().lock();
> try {
> if (cart != null && shouldDeleteCart) {
> log.debug("Deleting cart " + sessionID());
> int saveCounter = 0;
> do {
> if (cart.cleanAll()) {
> ec().deleteObject(cart);
> }
> saveCounter++;
> } while (!save() && saveCounter <= Application.SAVE_ATTEMPTS);
> }
> } catch (Exception e) {
> e.printStackTrace();
> }
finally {
> ec().unlock();
}
>
> log.info("Terminating session with ID:" + sessionID());
} finally {
> super.terminate();
}
> }
>
>
> ec() simply returns defaultEditingContext() (it's an ERXSession subclass)
>
> and save() is this:
>
> public boolean save() {
> boolean hasSaved = false;
> EOEditingContext editingContext = ec();
> try {
> editingContext.saveChanges();
> hasSaved = true;
> //Thrown for each eo that fails to save.
> } catch (EOGeneralAdaptorException saveException) {
> log.error("/*** OPTIMISTIC LOCKING FAILURE ***/ "+sessionID());
> log.error(saveException.getMessage());
> editingContext.revert();
> }
> return hasSaved;
> }
>
> This method makes me nervous, I don't trust it very much…
>
> Also I'm not sure about the explicit lock and unlock in the terminate method but since it's not in a R-R loop it might make sense to explicitly lock the ec, or not?
>
>
> Matteo
>
> On 19/mar/2013, at 18: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!
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
--
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