I noticed that there are only two types of exceptions handled by this handler 
so far: 

1.  WicketRuntimeException : Method onFormSubmitted of interface 
org.apache.wicket.markup.html.form.IFormSubmitListener targeted at [SearchForm 
[Component id = search_form]] on component [SearchForm [Component id = 
search_form]] threw an exception

2.  org.apache.wicket.request.mapper.StalePageException 

Could an expired session be the underline cause for both cases?

-----Original Message-----
From: Martin Grigorov [mailto:[email protected]] 
Sent: Tuesday, December 06, 2011 2:29 PM
To: [email protected]
Subject: Re: ConcurrentModificationException

On Tue, Dec 6, 2011 at 11:06 PM, Fang Lin <[email protected]> wrote:
> 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 ?"

It is called before. This is the place where your app can handle the problem. 
If this method return null then Wicket falls back to the default handling of 
exceptions (see DefaultExceptionMapper).
But in your case you always redirect to another page - ERROR_PAGE_URL.

>
> -----Original Message-----
> From: Martin Grigorov [mailto:[email protected]]
> Sent: Tuesday, December 06, 2011 12:47 PM
> To: [email protected]
> 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 <[email protected]> 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:[email protected]]
>> Sent: Monday, December 05, 2011 11:59 PM
>> To: [email protected]
>> 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 <[email protected]> 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(RequestHandlerS
>>> ta
>>> ck.java:176)
>>>
>>> org.apache.wicket.request.cycle.RequestCycle.onDetach(RequestCycle.j
>>> av
>>> 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(WicketFi
>>> lt
>>> er.java:162)
>>>
>>> org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.j
>>> av
>>> a:218)
>>>         at
>>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(App
>>> li
>>> cationFilterChain.java:235)
>>>        at
>>> org.apache.catalina.core.ApplicationFilterChain.doFilter(Application
>>> Fi
>>> lterChain.java:206)
>>>        at
>>> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapper
>>> Va
>>> lve.java:233)
>>>        at
>>> org.apache.catalina.core.StandardContextValve.invoke(StandardContext
>>> Va
>>> 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(StandardEngineVa
>>> lv
>>> e.java:109)
>>>        at
>>> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.ja
>>> va
>>> :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.j
>>> av
>>> a:703)
>>>        at
>>> org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSoc
>>> ke
>>> t.java:896)
>>>        at
>>> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(Thread
>>> Po
>>> 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: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>
>
>
> --
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>



--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to