Hi Fang,

Are there any other references to SessionErr page in your application aside
from its registration in ApplicationSettings? I ask because, as Martin
says, Wicket will only instantiate the PageExpiredErrorPage as a default
behavior if a custom RequestCycleListener does not provide an alternate
handler. Since your RequestCycleListener *always* provides a handler, I
don't see how the default behavior can apply.

Even more confusing is how you can get CME at that location. It's like the
SessionErr instantiation happens during the detach process. I'm just not
seeing how Wicket can do that itself.

Dan

On Tue, Dec 6, 2011 at 4:47 PM, Fang Lin <fang...@u.washington.edu> wrote:

> Should I use scheduleRequestHandlerAfterCurrent instead of
> replaceAllRequestHandlers ?
>
> -----Original Message-----
> From: Fang Lin [mailto:fang...@u.washington.edu]
> Sent: Tuesday, December 06, 2011 3:39 PM
> To: users@wicket.apache.org
> Subject: RE: ConcurrentModificationException
>
> I have just run into the ConcurrentModificationException on my dev server.
> Not that I can reproduce it, but I got more details:
>
> 1. my session has expired
>
> 2. the PageExpiredErrorPage SessionErr was invoked.  Internally it
> executed this statement:
>  public SessionErr ()
>  {
>    super ();
>    log.info ("Before replaceAllRequestHandlers");
>     getRequestCycle().replaceAllRequestHandlers (new SessionErrHandler());
>  // <===========
>   }
>
> 3.  SessionErrHandler was created,
>  public SessionErrHandler()
>  {
>    super(LOG_BACKIN_URL);
>    log.info ("RedirectRequest");
>  }
>
> Log:
> INFO 06 15:23:58.755 Before replaceAllRequestHandlers [m.p.SessionErr]
> INFO 06 15:23:58.755 RedirectRequest [m.SessionErrHandler] INFO 06
> 15:23:58.760 Before replaceAllRequestHandlers [m.p.SessionErr] INFO 06
> 15:23:58.760 RedirectRequest [m.SessionErrHandler]
>
> On the browser, HTTP Status 500 -
> java.util.ConcurrentModificationException
>
>  java.util.AbstractList$Itr.checkForComodification(AbstractList.java:372)
>        java.util.AbstractList$Itr.next(AbstractList.java:343)
>
>  
> org.apache.wicket.request.RequestHandlerStack.detach(RequestHandlerStack.java:176)
>
>  org.apache.wicket.request.cycle.RequestCycle.onDetach(RequestCycle.java:565)
>
>  org.apache.wicket.request.cycle.RequestCycle.detach(RequestCycle.java:508)
>
>  
> org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:284)
>
>  
> org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:162)
>
>  org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:218)
>
> -----Original Message-----
> From: Fang Lin [mailto:fang...@u.washington.edu]
> Sent: Tuesday, December 06, 2011 2:06 PM
> To: users@wicket.apache.org
> Subject: RE: ConcurrentModificationException
>
> I have been trying to reproduce it on our dev server this morning, but
> could not. However I did run into it twice on our production server
> yesterday.
>
> I wonder if you could answer my question  "Is this exception handler
> invoked before or after the ErrorPages ?"
>
> -----Original Message-----
> From: Martin Grigorov [mailto:mgrigo...@apache.org]
> Sent: Tuesday, December 06, 2011 12:47 PM
> To: users@wicket.apache.org
> Subject: Re: ConcurrentModificationException
>
> No, I don't see anything wrong here.
> If you are able to reproduce it then we can debug it.
>
> On Tue, Dec 6, 2011 at 9:40 PM, Fang Lin <fang...@u.washington.edu> wrote:
> > Thanks, Martin!
> >
> > In the init(), I have:
> > {
> >   getMarkupSettings().setStripWicketTags(true);
> >
> >    IApplicationSettings settings = getApplicationSettings();
> >    settings.setAccessDeniedPage(AccessErr.class);
> >    settings.setPageExpiredErrorPage(SessionErr.class);
> >    settings.setInternalErrorPage(InternalErr.class);
> >
> >    // #2 starts
> >     getRequestCycleListeners().add(new AbstractRequestCycleListener()
> > {
> >
> >        public IRequestHandler onException(RequestCycle cycle,
> > Exception e)
> >        {
> >          return new RedirectRequestHandler (ERROR_PAGE_URL);
> >        }
> >      });
> >    // #2 ends
> > }
> > Could the #2 code block be the cause?  Is this exception handler invoked
> before or after the ErrorPages ?
> >
> > Our authentication strategy is set up at Apache level.
> > This is what SessionErr class does:
> > getRequestCycle().replaceAllRequestHandlers (new SessionErrHandler());
> >
> > And SessionErrHandler redirect to the Login Servlet. And the Login
> Servlet will be routed to the WebLogin server.
> >
> > -----Original Message-----
> > From: Martin Grigorov [mailto:mgrigo...@apache.org]
> > Sent: Monday, December 05, 2011 11:59 PM
> > To: users@wicket.apache.org
> > Subject: Re: ConcurrentModificationException
> >
> > Hi,
> >
> > I don't see how this may happen.
> > The execution of RequestCycle is single threaded.
> > Do you have RequestCycleListener or something similar where you start
> another thread and you use the same instance of RequestCycle ?
> >
> > On Tue, Dec 6, 2011 at 2:31 AM, Fang Lin <fang...@u.washington.edu>
> wrote:
> >> When clicking on a link (i.e., ?5-1.ILinkListener-...) after a session
> expired, this error page shows up on my browser window:
> >> Exception report
> >> message
> >> description The server encountered an internal error () that prevented
> it from fulfilling this request.
> >> exception
> >> java.util.ConcurrentModificationException
> >>
> >> java.util.AbstractList$Itr.checkForComodification(AbstractList.java:3
> >> 7
> >> 2)
> >>
> >> java.util.AbstractList$Itr.next(AbstractList.java:343)
> >>
> >> org.apache.wicket.request.RequestHandlerStack.detach(RequestHandlerSt
> >> a
> >> ck.java:176)
> >>
> >> org.apache.wicket.request.cycle.RequestCycle.onDetach(RequestCycle.ja
> >> v
> >> a:565)
> >>
> >> org.apache.wicket.request.cycle.RequestCycle.detach(RequestCycle.java:
> >> 508)
> >>
> >> org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(
> >> R
> >> equestCycle.java:284)
> >>
> >> org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFil
> >> t
> >> er.java:162)
> >>
> >> org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.ja
> >> v
> >> a:218)
> >>         at
> >> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
> >> i
> >> cationFilterChain.java:235)
> >>        at
> >> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
> >> i
> >> lterChain.java:206)
> >>        at
> >> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperV
> >> a
> >> lve.java:233)
> >>        at
> >> org.apache.catalina.core.StandardContextValve.invoke(StandardContextV
> >> a
> >> lve.java:191)
> >>        at
> >> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j
> >> a
> >> va:127)
> >>        at
> >> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.j
> >> a
> >> va:102)
> >>        at
> >> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVal
> >> v
> >> e.java:109)
> >>        at
> >> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.jav
> >> a
> >> :298)
> >>        at
> >> org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:190)
> >>        at
> >> org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:291)
> >>        at
> >> org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:774)
> >>        at
> >> org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.ja
> >> v
> >> a:703)
> >>        at
> >> org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSock
> >> e
> >> t.java:896)
> >>        at
> >> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadP
> >> o
> >> ol.java:690)
> >>        at java.lang.Thread.run(Thread.java:662)
> >> This ConcurrentModificationException occurs about 70+ times on an
> application server daily.
> >> Wicket version 1.5.3.
> >> Any suggestion on how to avoid this?
> >> In the init method of sub-class of the WebApplication , I have:
> >>   IApplicationSettings settings = getApplicationSettings();
> >>    settings.setAccessDeniedPage(AccessErr.class);
> >>    settings.setPageExpiredErrorPage(SessionErr.class);
> >> settings.setInternalErrorPage(InternalErr.class);
> >> When a session expired, should it invoke the PageExpiredErrorPage?
> >
> > Yes. You make a request to a page, Wicket searches for this page in the
> stores, doesn't find it and throws PageExpiredException.
> > But, if the request url has the mount path then Wicket will create a new
> Page instance instead. If you have authentication strategy set up then you
> go to the Login page, otherwise this page will be rendered.
> >
> > If you are able to reproduce the problem in a quickstart attach it to
> Jira so we can debug it.
> > Thanks!
> >
> >> -Fang
> >>
> >>
> >
> >
> >
> > --
> > Martin Grigorov
> > jWeekend
> > Training, Consulting, Development
> > http://jWeekend.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> > For additional commands, e-mail: users-h...@wicket.apache.org
> >
>
>
>
> --
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

Reply via email to