Re: WoMonitor "Failed to contact ..."
Re: WoMonitor "Failed to contact ..."
- Subject: Re: WoMonitor "Failed to contact ..."
- From: Anjo Krank <email@hidden>
- Date: Fri, 1 May 2009 21:22:34 +0200
Uh. Why would it matter if you have two versions? There is only one in
the CP?
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.
What do you mean by that? You mean you didn't "ant clean" or what
before a full install build? We don't "merge", at least not that I
know of. You might end up with two jars in /Lib/Fra, but only one is
listed in the Info.plist...
Cheers, Anjo
Am 01.05.2009 um 19:20 schrieb Kieran Kelleher:
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