Re: WoMonitor "Failed to contact ..."
Re: WoMonitor "Failed to contact ..."
- Subject: Re: WoMonitor "Failed to contact ..."
- From: Kieran Kelleher <email@hidden>
- Date: Fri, 1 May 2009 13:20:22 -0400
FYI, Found the sessionstore deadlock culprit!
The root cause was an error in appendToResponse in EGWrapper which was
caused by my having TWO different version poi jars since Timo replaced
the jar in January. And as we know, when you install Wonder, it writes
over existing frameworks, so jars with different names are now merged,
included in the embedded build and MacOS ClassPath and cause havoc. In
any case, my fix for duplicate POI jars was to add ExcelGenerator to
the list of frameworks to "clean" (aka "rm -r" in my WOnder install
script).
Stack trace for the error that caused sessionstore deadlock.
java.lang.NoSuchMethodError:
org.apache.poi.hssf.usermodel.HSSFRow.createCell(I)Lorg/apache/poi/
hssf/usermodel/HSSFCell;
at er.excel.EGSimpleTableParser.parseTable(EGSimpleTableParser.java:
358)
at er.excel.EGSimpleTableParser.parseNode(EGSimpleTableParser.java:261)
at er.excel.EGSimpleTableParser.parse(EGSimpleTableParser.java:246)
at er.excel.EGSimpleTableParser.workbook(EGSimpleTableParser.java:122)
at er.excel.EGSimpleTableParser.data(EGSimpleTableParser.java:110)
at er.excel.EGWrapper.appendToResponse(EGWrapper.java:95)
at
com
.webobjects
.appserver
._private
.WOComponentReference.appendToResponse(WOComponentReference.java:111)
at
com
.webobjects
.appserver
._private.WODynamicGroup.appendChildrenToResponse(WODynamicGroup.java:
121)
at
com
.webobjects
.appserver
._private.WODynamicGroup.appendToResponse(WODynamicGroup.java:130)
at
com.webobjects.appserver.WOComponent.appendToResponse(WOComponent.java:
992)
.....
This link was not in my Selenium test ... it is now :-)
PS. On a different topic, the new POI version produces Excel sheet
full of garbage for me on this download, so until I get a chance to
figure that out I have replaced the Excel link with my commonly used
reobust CSV download feature instead.
On May 1, 2009, at 12:52 AM, Anjo Krank wrote:
Am 01.05.2009 um 04:12 schrieb Kieran Kelleher:
More good news ...... a side-effect of using ERX session store
deadlock detection and/or concurrent req handling=false is that
there are no CLOSE_WAITS and there are *no* threads blocked on
com.webobjects.appserver.WOSessionStore.checkOutSessionWithID(...),
not a single one in both of the instances that report these errors.
Yeah, it's a bit mis-named, since you get an exception right before
the double-checkout happens. So it's not checked-out and thus no
deadlock. In that regard, it's more "prevention".
Wonder normally gives me a detailed context information such as
previous page history and the exact component (actuallt nested
component tree) that was invoked to cause the error, but it seems
SessionInfo does not call that utility method
(ERXApplication#extraInformationForExceptionInContext(exception,
context)) .... I am going to try adding that to get the full
picture and redeploying.
Have fun... however, as you didn't actually set the session and it
hasn't restored the page, this util probably won't help...
It's been a while since I needed this, but:
- I normally implement ERXComponentActionRedirector.Restorable on my
pages so I get an easy URL for logging
- I did log both the context url and the restorable url
- if you know the page and the restore state, you can call it up and
look at the source and most likely, you will find the context id
- I still did a lot of debugging
Cheers, Anjo
_______________________________________________
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