[ 
https://issues.apache.org/jira/browse/WICKET-2294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12721691#action_12721691
 ] 

Dominik Drzewiecki commented on WICKET-2294:
--------------------------------------------

The weird thing is the fact that I couldn't reproduce this in our 
staging/development environment either. It only appeared in the production, 
under the heavy load. I found an issue reported at IBM: 
http://www-01.ibm.com/support/docview.wss?rs=180&uid=swg1PK69723 that *might* 
have something in common with my case, but the description is very terse, and 
ordered our admins to apply the fixpack containing this issue resolution. I've 
also built our app with wicket-1.4-SNAPSHOT containing exception chaining. 
Waiting for the bug to surface again (or hopefully not).

A little OT regarding Wicket on WebSphere. Wicket will no longer need to be run 
in servlet-mode on WAS from versions 6.1.0.27, and 7.0.0.5. I found, tracked 
down, reported and helped IBM guys solve the problem with their product. Here's 
more info: 
http://www-01.ibm.com/support/docview.wss?rs=0&q1=APAR+PK85015&uid=swg1PK85015&loc=en_US&cs=utf-8&cc=us&lang=all.
 Apart from that fix there need to be two more web container parameters set as 
described in aforementioned document. We're in the process of cautious 
migration to the filter, but our initial observations with wicket quickstart 
applications seem to work.

> CryptedUrlWebRequestCodingStrategy fails while decoding parameters after the 
> app has been up and running for quite some time.
> -----------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WICKET-2294
>                 URL: https://issues.apache.org/jira/browse/WICKET-2294
>             Project: Wicket
>          Issue Type: Bug
>          Components: wicket
>    Affects Versions: 1.4-RC4
>         Environment: WebSphere AppServer 6.1.0.x (servlet based wicket 
> application)
>            Reporter: Dominik Drzewiecki
>            Assignee: Igor Vaynberg
>            Priority: Critical
>             Fix For: 1.4-RC6
>
>
> After the application has been running for quite some time, I start getting 
> weird stacktraces:
> [5/29/09 10:38:40:953 CEST] 00000040 SystemOut     O [WebContainer : 11] INFO 
>  [NIK:49433203] o.a.w.p.h.r.CryptedUrlWebRequestCodingStrategy  - Invalid 
> URL: 
> resources/org.apache.wicket.markup.html.WicketEventReference/wicket-event.js?x=wnBdgbNM8h95LCyWTuURN3Cy9ygCdsR6,
>  message:null
> [5/29/09 10:38:40:953 CEST] 00000040 ServletWrappe E   SRVE0068E: Uncaught 
> exception thrown in one of the service methods of the servlet: 
> wicket.xxxxxxxx. Exception thrown : 
> org.apache.wicket.protocol.http.PageExpiredException: Invalid URL
>         at 
> org.apache.wicket.protocol.http.request.CryptedUrlWebRequestCodingStrategy.onError(CryptedUrlWebRequestCodingStrategy.java:293)
>         at 
> org.apache.wicket.protocol.http.request.CryptedUrlWebRequestCodingStrategy.onError(CryptedUrlWebRequestCodingStrategy.java:305)
>         at 
> org.apache.wicket.protocol.http.request.CryptedUrlWebRequestCodingStrategy.decodeURL(CryptedUrlWebRequestCodingStrategy.java:278)
>         at 
> org.apache.wicket.protocol.http.request.CryptedUrlWebRequestCodingStrategy.decode(CryptedUrlWebRequestCodingStrategy.java:108)
>         at 
> org.apache.wicket.protocol.http.WicketFilter.getLastModified(WicketFilter.java:1149)
>         at 
> org.apache.wicket.protocol.http.WicketServlet.getLastModified(WicketServlet.java:278)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:739)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
>         at 
> com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1096)
>         at 
> com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1037)
>         at 
> com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:145)
>         at 
> xxx.xxxxx.web.filters.AbstractMDCFilter.doFilter(AbstractMDCFilter.java:38)
>         at 
> com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:190)
>         at 
> com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:130)
>         at 
> xxx.xxxxx.xxxxxxxxxx.web.authorization.SecurityContextFilter.doFilter(SecurityContextFilter.java:39)
>         at 
> com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:190)
>         at 
> com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:130)
>         at 
> org.apache.wicket.protocol.http.servlet.WicketSessionFilter.doFilter(WicketSessionFilter.java:192)
>         at 
> com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:190)
>         at 
> com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:130)
>         at 
> com.ibm.ws.webcontainer.filter.WebAppFilterChain._doFilter(WebAppFilterChain.java:87)
>         at 
> com.ibm.ws.webcontainer.filter.WebAppFilterManager.doFilter(WebAppFilterManager.java:832)
>         at 
> com.ibm.ws.webcontainer.filter.WebAppFilterManager.doFilter(WebAppFilterManager.java:679)
>         at 
> com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:566)
>         at 
> com.ibm.ws.wswebcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:478)
>         at 
> com.ibm.ws.webcontainer.servlet.CacheServletWrapper.handleRequest(CacheServletWrapper.java:90)
>         at 
> com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:748)
>         at 
> com.ibm.ws.wswebcontainer.WebContainer.handleRequest(WebContainer.java:1466)
>         at 
> com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:119)
>         at 
> com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:458)
>         at 
> com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewInformation(HttpInboundLink.java:387)
>         at 
> com.ibm.ws.http.channel.inbound.impl.HttpICLReadCallback.complete(HttpICLReadCallback.java:102)
>         at 
> com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted(AioReadCompletionListener.java:165)
>         at 
> com.ibm.io.async.AbstractAsyncFuture.invokeCallback(AbstractAsyncFuture.java:217)
>         at 
> com.ibm.io.async.AsyncChannelFuture.fireCompletionActions(AsyncChannelFuture.java:161)
>         at com.ibm.io.async.AsyncFuture.completed(AsyncFuture.java:136)
>         at com.ibm.io.async.ResultHandler.complete(ResultHandler.java:195)
>         at 
> com.ibm.io.async.ResultHandler.runEventProcessingLoop(ResultHandler.java:743)
>         at com.ibm.io.async.ResultHandler$2.run(ResultHandler.java:873)
>         at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1473)
> If, however, I grab the offending url and forge a request using wget or 
> simply paste it into address bar of the browser, I receive the proper 
> response (HTTP 200 and expected output instead of HTTP 500)
> It is difficult to track down as I observe this in our production environment 
> (no debugging :/) serving an application internally, before it goes gold. I 
> cannot reproduce this in the staging nor development environment having the 
> very same setup but serving way smaller traffic. Application server restart 
> solves (or should i say works around temporarily) the problem. Any help would 
> be appreciated.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to