On Jan 28, 2008, at 12:23 PM, Dov Rosenberg wrote:
We have a WO app that we deploy as a servlet into Tomcat. We have
had occasions where Tomcat will hang causing our application to
become inaccessible. I think I have narrowed the problem down an
issue that is logged when this occurs.
Exception occurred while handling request:
com.webobjects.appserver.WOPageNotFoundException: <.../
Application>: Unable to create page 'OR3Vn2AxtWCKZtdwx7mAJ0/apps/
infocenter/resources/images/Revoke-button.gif'.
<http-8226-Processor221>
com.webobjects.appserver.WOPageNotFoundException: <../
Application>: Unable to create page 'OR3Vn2AxtWCKZtdwx7mAJ0/apps/
infocenter/resources/images/Revoke-button.gif'.
at com.webobjects.appserver.WOApplication.pageWithName
(WOApplication.java:1968)
at
com.webobjects.appserver._private.WOComponentRequestHandler._dispatchW
ithPreparedSession(WOComponentRequestHandler.java:273)
at
com.webobjects.appserver._private.WOComponentRequestHandler._dispatchW
ithPreparedApplication(WOComponentRequestHandler.java:322)
I think that is where the problem is. This exception is not expected
and when it happens the session has been checked out and never gets
checked back in. Please file a bug report on this.
at
com.webobjects.appserver._private.WOComponentRequestHandler._handleReq
uest(WOComponentRequestHandler.java:358)
at
com.webobjects.appserver._private.WOComponentRequestHandler.handleRequ
est(WOComponentRequestHandler.java:435)
at com.webobjects.appserver.WOApplication.dispatchRequest
(WOApplication.java:1306)
at
com.webobjects.jspservlet._WOApplicationWrapper.servletDispatchRequest
(_WOApplicationWrapper.java:118)
at
com.webobjects.jspservlet.WOServletAdaptor._handleRequest
(WOServletAdaptor.java:678)
at com.webobjects.jspservlet.WOServletAdaptor.doGet
(WOServletAdaptor.java:660)
......
Tomcat shows the stuck threads urls as http://<host>:<port>/MyApp/
WebObjects/MyApp.woa/wo/OR3Vn2AxtWCKZtdwx7mAJ0/apps/infocenter/
resources/images/Revoke-button.gif.
This resource was set as a relative URL in a piece of content that
was cut and pasted into our tool and was being previewed. The
browser saw the relative URL ( /apps/infocenter/resources/images/
Revoke-button.gif) and appended it to the end of the WO app http://
<host>:<port>/MyApp/WebObjects/MyApp.woa/wo. This sent the request
thru the WebObjects servlet. This ended up causing the WOSession to
be locked up trying to resolve the path to the resource. The
Session could not be checked out from the WOSessionStore,
eventually causing all of the new incoming requests to pile up and
kill both Tomcat and our WO application. The thread dump when the
problem occurred looked like:
...
at java.lang.Object.wait(Native Method)
- waiting on <0x8c89e608> (a
com.webobjects.appserver.WOSessionStore$TimeoutEntry)
at java.lang.Object.wait(Unknown Source)
at
com.webobjects.appserver.WOSessionStore.checkOutSessionWithID
(WOSessionStore.java:207)
- locked <0x8c89e608> (a
com.webobjects.appserver.WOSessionStore$TimeoutEntry)
at
com.webobjects.appserver.WOApplication.restoreSessionWithID
(WOApplication.java:1546)
at
com.webobjects.appserver._private.WOComponentRequestHandler._dispatchW
ithPreparedApplication(WOComponentRequestHandler.java:314)
at
com.webobjects.appserver._private.WOComponentRequestHandler._handleReq
uest(WOComponentRequestHandler.java:358)
at
com.webobjects.appserver._private.WOComponentRequestHandler.handleRequ
est(WOComponentRequestHandler.java:435)
at com.webobjects.appserver.WOApplication.dispatchRequest
(WOApplication.java:1306)
at
com.webobjects.jspservlet._WOApplicationWrapper.servletDispatchRequest
(_WOApplicationWrapper.java:118)
at
com.webobjects.jspservlet.WOServletAdaptor._handleRequest
(WOServletAdaptor.java:678)
...
It looks like the only way to fix the problem is to filter unknown
requests from making it to the WO adaptor in the first place. Seems
like the WOServletAdaptor should be a more robust in dealing with
non IM requests that are coming in. The problem is with at least WO
5.2 and higher.
Any thoughts or feedback are welcome.
You might be able to check for a session in dispatchRequest, after
calling super, and then check it in. In most cases this would lead
to two checkins, I have not looked to see what problems this might
cause.
Another idea is to override pageWithName, catch this exception, and
return an empty (e.g. dummy) component that contains the error
message. I think that would be safer.
Chuck
--
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/products/practical_webobjects
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
