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 16:03:25 -0400
On May 1, 2009, at 3:22 PM, Anjo Krank wrote:
Uh. Why would it matter if you have two versions? There is only one
in the CP?
That is what I would have expected too, but *both* were in the
generated classpath, merely by the fact that it existed in the
installed framework. Here is the cp file. http://web.me.com/kelleherk/MiscStuff/MacOSClassPath.txt
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"
IIRC "ant clean" only deletes stuff in Roots ...... not the actual /
Library/Frameworks which is where the embedded frameworks are pulled
from. BTW, I always do this (in my Wonder update script):
ant clean
ant frameworks
ant frameworks.install
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...
(FYI, I am on WO 5.3.3, WOLips 3.4.5693 nightly)
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