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:37
> 2)
>                    
> java.util.AbstractList$Itr.next(AbstractList.java:343)
>                    
> org.apache.wicket.request.RequestHandlerStack.detach(RequestHandlerSta
> ck.java:176)
>                    
> org.apache.wicket.request.cycle.RequestCycle.onDetach(RequestCycle.jav
> 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(WicketFilt
> er.java:162)
>                    
> org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.jav
> a:218)
>         at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appli
> cationFilterChain.java:235)
>        at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFi
> lterChain.java:206)
>        at 
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperVa
> lve.java:233)
>        at 
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextVa
> lve.java:191)
>        at 
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.ja
> va:127)
>        at 
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.ja
> va:102)
>        at 
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValv
> e.java:109)
>        at 
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java
> :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.jav
> a:703)
>        at 
> org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocke
> t.java:896)
>        at 
> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPo
> 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

Reply via email to