[
https://issues.apache.org/jira/browse/WICKET-2294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dominik Drzewiecki reopened WICKET-2294:
----------------------------------------
No, the session is definitely *not expired*. It is wicket that for some reason
is considering the session stale. In fact the session is still there, because
the application works almost fine - I can use the app successfully but observe
occasional HTTP 500 that result in some images or scripts not being retrieved.
As I mentioned earlier the request that failed, when replayed using wget or the
browser itself succeeds. Please notice that my app is using url rewriting for
keeping track of the session, so the url replayed by wget holds a reference to
the same valid session.
> 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-RC5
>
>
> 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.
