You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Fang Lin <Fa...@u.washington.edu> on 2011/12/06 02:31:24 UTC
ConcurrentModificationException
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: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)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.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.java:703)
at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:896)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.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?
-Fang
RE: ConcurrentModificationException
Posted by Fang Lin <Fa...@u.washington.edu>.
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:mgrigorov@apache.org]
Sent: Tuesday, December 06, 2011 2:29 PM
To: users@wicket.apache.org
Subject: Re: ConcurrentModificationException
On Tue, Dec 6, 2011 at 11:06 PM, Fang Lin <Fa...@u.washington.edu> 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:mgrigorov@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 <Fa...@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:mgrigorov@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 <Fa...@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(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: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>
>
>
> --
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: ConcurrentModificationException
Posted by Martin Grigorov <mg...@apache.org>.
On Tue, Dec 6, 2011 at 11:06 PM, Fang Lin <Fa...@u.washington.edu> 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:mgrigorov@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 <Fa...@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:mgrigorov@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 <Fa...@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-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>
>
>
> --
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: ConcurrentModificationException
Posted by Fang Lin <Fa...@u.washington.edu>.
Finally got this fixed.
1. Make one CustomExceptionListener handles all the Exceptions.
In IRequestHandler onException(RequestCycle cycle, Exception e),
As the parameter Exception is not the original exception in the WebPage. After getting the initial cause Throwable from the Exception, the error handler works.
2.
Changed replaceAllRequestHandlers to scheduleRequestHandlerAfterCurrent when redirecting to the non-Wicket page.
Thank you both Dan and Martin!
-Fang
-----Original Message-----
From: Dan Retzlaff [mailto:dretzlaff@gmail.com]
Sent: Wednesday, December 07, 2011 10:08 PM
To: users@wicket.apache.org
Subject: Re: ConcurrentModificationException
That looks like something to do with your custom session business, so I
don't think I can help you.
By the way, I think a more direct and common idiom for redirect handlers is:
return new RenderPageRequestHandler(new PageProvider(TargetPage.class));
On Wed, Dec 7, 2011 at 9:59 PM, Fang Lin <Fa...@u.washington.edu> wrote:
> Hi Dan,
>
> I removed the error handling logic from the WebPage and have the
> CustomExceptionListener handles all the Exceptions.
>
> @Override
> public IRequestHandler onException(RequestCycle cycle, Exception e)
> {
> logErr (cycle, e);
> if (e instanceof InvalidSession) {
> return new SessionErrHandler();
> }
>
> if (e instanceof GetFailedException) {
> return new DbErrHandler();
> }
>
> if (e instanceof ParameterException) {
> return new ParamErrHandler();
> }
>
> if (e instanceof DisallowedUwnetidException) {
> return new AccessErrHandler();
> }
>
> if (e instanceof SslException) {
> return new SslErrHandler();
> }
>
> return new RuntimeErrHandler();
> }
> Each of these handlers redirect to a static error page.
>
> Now I get this error:
>
> Can't instantiate page using constructor 'public
> myuw.page.Main(org.apache.wicket.request.mapper.parameter.PageParameters)'
> and argument 'f=[d], tab=[1]'. Might be it doesn't exist, may be it is not
> visible (public).
> at
> org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:196)
> at
> org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:97)
> at
> org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:47)
> at
> org.apache.wicket.DefaultMapperContext.newPageInstance(DefaultMapperContext.java:107)
> at
> org.apache.wicket.request.handler.PageProvider.resolvePageInstance(PageProvider.java:264)
> at
> org.apache.wicket.request.handler.PageProvider.getPageInstance(PageProvider.java:165)
> at
> org.apache.wicket.request.handler.ListenerInterfaceRequestHandler.getPage(ListenerInterfaceRequestHandler.java:100)
> at
> org.apache.wicket.request.handler.ListenerInterfaceRequestHandler.respond(ListenerInterfaceRequestHandler.java:165)
> at
> org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:750)
> at
> org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64)
> at
> org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:252)
> at
> org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:209)
> at
> org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:280)
> at
> org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:162)
> at
> org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:218)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> Caused by: java.lang.reflect.InvocationTargetException: null
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
> at
> org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:173)
> at
> org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:97)
> at
> org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:47)
> at
> org.apache.wicket.DefaultMapperContext.newPageInstance(DefaultMapperContext.java:107)
> at
> org.apache.wicket.request.handler.PageProvider.resolvePageInstance(PageProvider.java:264)
> at
> org.apache.wicket.request.handler.PageProvider.getPageInstance(PageProvider.java:165)
> at
> org.apache.wicket.request.handler.ListenerInterfaceRequestHandler.getPage(ListenerInterfaceRequestHandler.java:100)
> at
> org.apache.wicket.request.handler.ListenerInterfaceRequestHandler.respond(ListenerInterfaceRequestHandler.java:165)
> at
> org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:750)
> at
> org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64)
> at
> org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:252)
> at
> org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:209)
> at
> org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:280)
> at
> org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:162)
> at
> org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:218)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> Caused by:
> edu.washington.cac.myuw.servlet.session.NoExistingSessionException: An
> existing user but the HttpSession is null
> at
> edu.washington.cac.myuw.servlet.session.UwSession.<init>(Unknown Source)
> at myuw.sessiono.MyUWSession.<init>(Unknown Source)
> at myuw.sessiono.MyUWSession.<init>(Unknown Source)
> at myuw.session.MyuwSession.setMyUWSession(Unknown Source)
> at myuw.page.BasePage.setMyUWSession(Unknown Source)
> at myuw.page.Main.setMyUWSession(Unknown Source)
> at myuw.page.BasePage.setup(Unknown Source)
> at myuw.page.Main.<init>(Unknown Source)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
> at
> org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:173)
> at
> org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:97)
> at
> org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:47)
> at
> org.apache.wicket.DefaultMapperContext.newPageInstance(DefaultMapperContext.java:107)
> at
> org.apache.wicket.request.handler.PageProvider.resolvePageInstance(PageProvider.java:264)
> at
> org.apache.wicket.request.handler.PageProvider.getPageInstance(PageProvider.java:165)
> at
> org.apache.wicket.request.handler.ListenerInterfaceRequestHandler.getPage(ListenerInterfaceRequestHandler.java:100)
> at
> org.apache.wicket.request.handler.ListenerInterfaceRequestHandler.respond(ListenerInterfaceRequestHandler.java:165)
> at
> org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:750)
>
>
> -----Original Message-----
> From: Fang Lin [mailto:Fanglin@u.washington.edu]
> Sent: Wednesday, December 07, 2011 5:17 PM
> To: 'users@wicket.apache.org'
> Subject: RE: ConcurrentModificationException
>
> Yes, that sounds like a better way as the handling logic is the same.
> Thanks!
>
> Here is the stack trace when a ConcurrentModificationException occurs:
> ERROR 07 17:08:51.968 setup: [m.p.BasePage]
> edu.washington.cac.myuw.servlet.session.NoExistingSessionException: An
> existing user but the HttpSession is null
> at edu.washington.cac.myuw.servlet.session.UwSession.<init>(Unknown
> Source)
> at myuw.sessiono.MyUWSession.<init>(Unknown Source)
> at myuw.sessiono.MyUWSession.<init>(Unknown Source)
> at myuw.session.MyuwSession.setMyUWSession(Unknown Source)
> at myuw.page.BasePage.setMyUWSession(Unknown Source)
> at myuw.page.BasePage.setup(Unknown Source)
> at myuw.page.Main.<init>(Unknown Source)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
> at
> org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:177)
> at
> org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:68)
> at
> org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:47)
> at
> org.apache.wicket.DefaultMapperContext.newPageInstance(DefaultMapperContext.java:103)
> at
> org.apache.wicket.request.handler.PageProvider.resolvePageInstance(PageProvider.java:264)
> at
> org.apache.wicket.request.handler.PageProvider.getPageInstance(PageProvider.java:165)
> at
> org.apache.wicket.request.handler.ListenerInterfaceRequestHandler.getPage(ListenerInterfaceRequestHandler.java:100)
> at
> org.apache.wicket.request.handler.ListenerInterfaceRequestHandler.respond(ListenerInterfaceRequestHandler.java:165)
>
> INFO 07 17:08:51.968 >>>Route to User login [m.SessionErrHandler]
> ERROR 07 17:08:51.976 setup: [m.p.BasePage]
> edu.washington.cac.myuw.servlet.session.NoExistingSessionException: An
> existing user but the HttpSession is null
> at edu.washington.cac.myuw.servlet.session.UwSession.<init>(Unknown
> Source)
> at myuw.sessiono.MyUWSession.<init>(Unknown Source)
> at myuw.sessiono.MyUWSession.<init>(Unknown Source)
> at myuw.session.MyuwSession.setMyUWSession(Unknown Source)
> at myuw.page.BasePage.setMyUWSession(Unknown Source)
> at myuw.page.BasePage.setup(Unknown Source)
> at myuw.page.Main.<init>(Unknown Source)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
> at
> org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:177)
> at
> org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:68)
> at
> org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:47)
> at
> org.apache.wicket.DefaultMapperContext.newPageInstance(DefaultMapperContext.java:103)
> at
> org.apache.wicket.request.handler.PageProvider.resolvePageInstance(PageProvider.java:264)
> at
> org.apache.wicket.request.handler.PageProvider.getPageInstance(PageProvider.java:165)
> at
> org.apache.wicket.request.handler.PageAndComponentProvider.getComponent(PageAndComponentProvider.java:144)
> at
> org.apache.wicket.request.handler.logger.ListenerInterfaceLogData.tryToGetComponentClass(ListenerInterfaceLogData.java:80)
>
> INFO 07 17:08:51.976 >>>Route to User login [m.SessionErrHandler]
>
>
> -----Original Message-----
> From: Dan Retzlaff [mailto:dretzlaff@gmail.com]
> Sent: Wednesday, December 07, 2011 4:48 PM
> To: users@wicket.apache.org
> Subject: Re: ConcurrentModificationException
>
> Gotcha. Well I'm still confused, but I do have a suggestion. Instead of
> catching and handling exceptions like this in your page, let them propagate
> out and handle them when Wicket calls your
> RequestCycleListener#onException(). No point in finishing the page
> construction/rendering, right?
>
> On Wed, Dec 7, 2011 at 4:27 PM, Fang Lin <Fa...@u.washington.edu> wrote:
>
> > Not sure if the exception occurs at the commit/detach phase of a request.
> > The session is always verified before generating the page content. See
> the
> > stack trace:
> > [m.p.BasePage]
> > edu.washington.cac.myuw.servlet.session.NoExistingSessionException: An
> > existing user but the HttpSession is null
> > at
> edu.washington.cac.myuw.servlet.session.UwSession.<init>(Unknown
> > Source)
> > at myuw.sessiono.MyUWSession.<init>(Unknown Source)
> > at myuw.session.MyuwSession.setMyUWSession(Unknown Source)
> > at myuw.page.BasePage.setMyUWSession(Unknown Source)
> > at myuw.page.BasePage.setup(Unknown Source)
> > at myuw.page.Main.<init>(Unknown Source)
> > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> > Method)
> > at
> >
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> > at
> >
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> > at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
> > at
> >
> org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:173)
> > at
> >
> org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:97)
> > at
> >
> org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:47)
> > at
> >
> org.apache.wicket.DefaultMapperContext.newPageInstance(DefaultMapperContext.java:107)
> > at
> >
> org.apache.wicket.request.handler.PageProvider.resolvePageInstance(PageProvider.java:264)
> > at
> >
> org.apache.wicket.request.handler.PageProvider.getPageInstance(PageProvider.java:165)
> > at
> >
> org.apache.wicket.request.handler.ListenerInterfaceRequestHandler.getPage(ListenerInterfaceRequestHandler.java:100)
> > at
> >
> org.apache.wicket.request.handler.ListenerInterfaceRequestHandler.respond(ListenerInterfaceRequestHandler.java:165)
> >
> >
> > -----Original Message-----
> > From: Dan Retzlaff [mailto:dretzlaff@gmail.com]
> > Sent: Wednesday, December 07, 2011 4:01 PM
> > To: users@wicket.apache.org
> > Subject: Re: ConcurrentModificationException
> >
> > So it sounds like
> > 1. you've introduced a custom layer between Wicket and the servlet
> session,
> > 2. that custom layer can throw an exception called InvalidSession while
> > Wicket tries to save a page into it (during request cycle commit/detach),
> > and
> > 3. that exception gets into a handleException() method which calls
> > setResponsePage, adding a new request handler to the request cycle being
> > detached.
> >
> > If that's right, then it's probably worth mentioning that the
> commit/detach
> > phase of a request is way too late to be changing response pages. The
> best
> > you can do at that point is log an exception.
> >
> > (Apologies if I misunderstand you; it sounds fairly unconventional but
> > maybe I just haven't pieced it together correctly.)
> >
> > On Wed, Dec 7, 2011 at 3:05 PM, Fang Lin <Fa...@u.washington.edu>
> wrote:
> >
> > > That's very helpful. Thanks for sharing your code!
> > >
> > > We use a custom session manager, which verifies the session. When the
> > > underline HttpSession is expired, it throws a sub-class of
> InvalidSession
> > > exception.
> > >
> > > All the Throwable in the WebPage is handled by this method:
> > > protected void handleException(Throwable e)
> > > {
> > > if (e instanceof InvalidSession) {
> > > setResponsePage(new SessionErr()); // <== gets triggered before
> > > Wicket's PageExpiredException
> > > return;
> > > }
> > > ErrPage.logErr (getLoggerId(),
> > > e.toString(),
> > > getHttpServletRequest());
> > > if (e instanceof ParameterException) {
> > > setResponsePage(new ParamErr());
> > > return;
> > > }
> > > setResponsePage(new InternalErr());
> > > return;
> > > }
> > >
> > >
> > > public class SessionErr extends WebPage {
> > > public SessionErr ()
> > > {
> > > super ();
> > > getRequestCycle().replaceAllRequestHandlers (new
> > SessionErrHandler());
> > > }
> > > }
> > >
> > > public class SessionErrHandler extends RedirectRequestHandler {
> > > public SessionErrHandler()
> > > {
> > > super(LOG_BACKIN_URL);
> > > }
> > > }
> > >
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Dan Retzlaff [mailto:dretzlaff@gmail.com]
> > > Sent: Wednesday, December 07, 2011 1:56 PM
> > > To: users@wicket.apache.org
> > > Subject: Re: ConcurrentModificationException
> > >
> > > If you want to get to the bottom of that CME, then I'd investigate
> usage
> > #1
> > > since you've presented usages #2 and #3 and they look okay (barring a
> > > Wicket bug).
> > >
> > > In any case, I haven't been working with 1.5 very long but for what
> it's
> > > worth we have this as our custom RequestCycleListener:
> > > http://pastebin.com/SnS9PS8N
> > >
> > > Note that returning null allows Wicket to employ the registered
> > > PageExpiredErrorPage and AccessDeniedPage pages, and we set both to our
> > > Login page. The ErrorPage is our customized "oops" page for truly
> > > unexpected exceptions.
> > >
> > > On Wed, Dec 7, 2011 at 1:36 PM, Fang Lin <Fa...@u.washington.edu>
> > wrote:
> > >
> > > > Hi Dan,
> > > >
> > > >
> > > >
> > > > Thanks for the response and the question!
> > > >
> > > >
> > > >
> > > > I have put exception handler in three places:
> > > >
> > > >
> > > >
> > > > 1. In the WebPage via a try and catch
> > > >
> > > >
> > > >
> > > > 2. In the custom RequestCycleListener
> > > >
> > > >
> > > > 3. In the ApplicationSettings
> > > >
> > > >
> > > >
> > > > Because I wasn't clear about the relationship between them, I put
> them
> > > > everywhere just in case. I was also wondering why handler got invoked
> > > twice.
> > > >
> > > >
> > > >
> > > > It looks like #2 and #3 are unnecessary/redundant unless they handles
> > > > different exceptions.
> > > >
> > > > What would be the recommended approach for exception handling?
> > > >
> > > >
> > > >
> > > > -Fang
> > > >
> > > > -----Original Message-----
> > > > From: Dan Retzlaff [mailto:dretzlaff@gmail.com]
> > > > Sent: Wednesday, December 07, 2011 9:40 AM
> > > > To: users@wicket.apache.org
> > > > Subject: Re: ConcurrentModificationException
> > > >
> > > >
> > > >
> > > > 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 <Fa...@u.washington.edu>
> > > wrote:
> > > >
> > > >
> > > >
> > > > > Should I use scheduleRequestHandlerAfterCurrent instead of
> > > >
> > > > > replaceAllRequestHandlers ?
> > > >
> > > > >
> > > >
> > > > > -----Original Message-----
> > > >
> > > > > From: Fang Lin [mailto:Fanglin@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:Fanglin@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:mgrigorov@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 <Fanglin@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:mgrigorov@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 <
> Fanglin@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-unsubscribe@wicket.apache.org
> > > >
> > > > > > For additional commands, e-mail: users-help@wicket.apache.org
> > > >
> > > > > >
> > > >
> > > > >
> > > >
> > > > >
> > > >
> > > > >
> > > >
> > > > > --
> > > >
> > > > > Martin Grigorov
> > > >
> > > > > jWeekend
> > > >
> > > > > Training, Consulting, Development
> > > >
> > > > > http://jWeekend.com
> > > >
> > > > >
> > > >
> > > > >
> ---------------------------------------------------------------------
> > > >
> > > > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > >
> > > > > For additional commands, e-mail: users-help@wicket.apache.org
> > > >
> > > > >
> > > >
> > > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > For additional commands, e-mail: users-help@wicket.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: ConcurrentModificationException
Posted by Dan Retzlaff <dr...@gmail.com>.
That looks like something to do with your custom session business, so I
don't think I can help you.
By the way, I think a more direct and common idiom for redirect handlers is:
return new RenderPageRequestHandler(new PageProvider(TargetPage.class));
On Wed, Dec 7, 2011 at 9:59 PM, Fang Lin <Fa...@u.washington.edu> wrote:
> Hi Dan,
>
> I removed the error handling logic from the WebPage and have the
> CustomExceptionListener handles all the Exceptions.
>
> @Override
> public IRequestHandler onException(RequestCycle cycle, Exception e)
> {
> logErr (cycle, e);
> if (e instanceof InvalidSession) {
> return new SessionErrHandler();
> }
>
> if (e instanceof GetFailedException) {
> return new DbErrHandler();
> }
>
> if (e instanceof ParameterException) {
> return new ParamErrHandler();
> }
>
> if (e instanceof DisallowedUwnetidException) {
> return new AccessErrHandler();
> }
>
> if (e instanceof SslException) {
> return new SslErrHandler();
> }
>
> return new RuntimeErrHandler();
> }
> Each of these handlers redirect to a static error page.
>
> Now I get this error:
>
> Can't instantiate page using constructor 'public
> myuw.page.Main(org.apache.wicket.request.mapper.parameter.PageParameters)'
> and argument 'f=[d], tab=[1]'. Might be it doesn't exist, may be it is not
> visible (public).
> at
> org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:196)
> at
> org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:97)
> at
> org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:47)
> at
> org.apache.wicket.DefaultMapperContext.newPageInstance(DefaultMapperContext.java:107)
> at
> org.apache.wicket.request.handler.PageProvider.resolvePageInstance(PageProvider.java:264)
> at
> org.apache.wicket.request.handler.PageProvider.getPageInstance(PageProvider.java:165)
> at
> org.apache.wicket.request.handler.ListenerInterfaceRequestHandler.getPage(ListenerInterfaceRequestHandler.java:100)
> at
> org.apache.wicket.request.handler.ListenerInterfaceRequestHandler.respond(ListenerInterfaceRequestHandler.java:165)
> at
> org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:750)
> at
> org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64)
> at
> org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:252)
> at
> org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:209)
> at
> org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:280)
> at
> org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:162)
> at
> org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:218)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> Caused by: java.lang.reflect.InvocationTargetException: null
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
> at
> org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:173)
> at
> org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:97)
> at
> org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:47)
> at
> org.apache.wicket.DefaultMapperContext.newPageInstance(DefaultMapperContext.java:107)
> at
> org.apache.wicket.request.handler.PageProvider.resolvePageInstance(PageProvider.java:264)
> at
> org.apache.wicket.request.handler.PageProvider.getPageInstance(PageProvider.java:165)
> at
> org.apache.wicket.request.handler.ListenerInterfaceRequestHandler.getPage(ListenerInterfaceRequestHandler.java:100)
> at
> org.apache.wicket.request.handler.ListenerInterfaceRequestHandler.respond(ListenerInterfaceRequestHandler.java:165)
> at
> org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:750)
> at
> org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64)
> at
> org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:252)
> at
> org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:209)
> at
> org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:280)
> at
> org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:162)
> at
> org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:218)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> Caused by:
> edu.washington.cac.myuw.servlet.session.NoExistingSessionException: An
> existing user but the HttpSession is null
> at
> edu.washington.cac.myuw.servlet.session.UwSession.<init>(Unknown Source)
> at myuw.sessiono.MyUWSession.<init>(Unknown Source)
> at myuw.sessiono.MyUWSession.<init>(Unknown Source)
> at myuw.session.MyuwSession.setMyUWSession(Unknown Source)
> at myuw.page.BasePage.setMyUWSession(Unknown Source)
> at myuw.page.Main.setMyUWSession(Unknown Source)
> at myuw.page.BasePage.setup(Unknown Source)
> at myuw.page.Main.<init>(Unknown Source)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
> at
> org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:173)
> at
> org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:97)
> at
> org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:47)
> at
> org.apache.wicket.DefaultMapperContext.newPageInstance(DefaultMapperContext.java:107)
> at
> org.apache.wicket.request.handler.PageProvider.resolvePageInstance(PageProvider.java:264)
> at
> org.apache.wicket.request.handler.PageProvider.getPageInstance(PageProvider.java:165)
> at
> org.apache.wicket.request.handler.ListenerInterfaceRequestHandler.getPage(ListenerInterfaceRequestHandler.java:100)
> at
> org.apache.wicket.request.handler.ListenerInterfaceRequestHandler.respond(ListenerInterfaceRequestHandler.java:165)
> at
> org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:750)
>
>
> -----Original Message-----
> From: Fang Lin [mailto:Fanglin@u.washington.edu]
> Sent: Wednesday, December 07, 2011 5:17 PM
> To: 'users@wicket.apache.org'
> Subject: RE: ConcurrentModificationException
>
> Yes, that sounds like a better way as the handling logic is the same.
> Thanks!
>
> Here is the stack trace when a ConcurrentModificationException occurs:
> ERROR 07 17:08:51.968 setup: [m.p.BasePage]
> edu.washington.cac.myuw.servlet.session.NoExistingSessionException: An
> existing user but the HttpSession is null
> at edu.washington.cac.myuw.servlet.session.UwSession.<init>(Unknown
> Source)
> at myuw.sessiono.MyUWSession.<init>(Unknown Source)
> at myuw.sessiono.MyUWSession.<init>(Unknown Source)
> at myuw.session.MyuwSession.setMyUWSession(Unknown Source)
> at myuw.page.BasePage.setMyUWSession(Unknown Source)
> at myuw.page.BasePage.setup(Unknown Source)
> at myuw.page.Main.<init>(Unknown Source)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
> at
> org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:177)
> at
> org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:68)
> at
> org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:47)
> at
> org.apache.wicket.DefaultMapperContext.newPageInstance(DefaultMapperContext.java:103)
> at
> org.apache.wicket.request.handler.PageProvider.resolvePageInstance(PageProvider.java:264)
> at
> org.apache.wicket.request.handler.PageProvider.getPageInstance(PageProvider.java:165)
> at
> org.apache.wicket.request.handler.ListenerInterfaceRequestHandler.getPage(ListenerInterfaceRequestHandler.java:100)
> at
> org.apache.wicket.request.handler.ListenerInterfaceRequestHandler.respond(ListenerInterfaceRequestHandler.java:165)
>
> INFO 07 17:08:51.968 >>>Route to User login [m.SessionErrHandler]
> ERROR 07 17:08:51.976 setup: [m.p.BasePage]
> edu.washington.cac.myuw.servlet.session.NoExistingSessionException: An
> existing user but the HttpSession is null
> at edu.washington.cac.myuw.servlet.session.UwSession.<init>(Unknown
> Source)
> at myuw.sessiono.MyUWSession.<init>(Unknown Source)
> at myuw.sessiono.MyUWSession.<init>(Unknown Source)
> at myuw.session.MyuwSession.setMyUWSession(Unknown Source)
> at myuw.page.BasePage.setMyUWSession(Unknown Source)
> at myuw.page.BasePage.setup(Unknown Source)
> at myuw.page.Main.<init>(Unknown Source)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
> at
> org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:177)
> at
> org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:68)
> at
> org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:47)
> at
> org.apache.wicket.DefaultMapperContext.newPageInstance(DefaultMapperContext.java:103)
> at
> org.apache.wicket.request.handler.PageProvider.resolvePageInstance(PageProvider.java:264)
> at
> org.apache.wicket.request.handler.PageProvider.getPageInstance(PageProvider.java:165)
> at
> org.apache.wicket.request.handler.PageAndComponentProvider.getComponent(PageAndComponentProvider.java:144)
> at
> org.apache.wicket.request.handler.logger.ListenerInterfaceLogData.tryToGetComponentClass(ListenerInterfaceLogData.java:80)
>
> INFO 07 17:08:51.976 >>>Route to User login [m.SessionErrHandler]
>
>
> -----Original Message-----
> From: Dan Retzlaff [mailto:dretzlaff@gmail.com]
> Sent: Wednesday, December 07, 2011 4:48 PM
> To: users@wicket.apache.org
> Subject: Re: ConcurrentModificationException
>
> Gotcha. Well I'm still confused, but I do have a suggestion. Instead of
> catching and handling exceptions like this in your page, let them propagate
> out and handle them when Wicket calls your
> RequestCycleListener#onException(). No point in finishing the page
> construction/rendering, right?
>
> On Wed, Dec 7, 2011 at 4:27 PM, Fang Lin <Fa...@u.washington.edu> wrote:
>
> > Not sure if the exception occurs at the commit/detach phase of a request.
> > The session is always verified before generating the page content. See
> the
> > stack trace:
> > [m.p.BasePage]
> > edu.washington.cac.myuw.servlet.session.NoExistingSessionException: An
> > existing user but the HttpSession is null
> > at
> edu.washington.cac.myuw.servlet.session.UwSession.<init>(Unknown
> > Source)
> > at myuw.sessiono.MyUWSession.<init>(Unknown Source)
> > at myuw.session.MyuwSession.setMyUWSession(Unknown Source)
> > at myuw.page.BasePage.setMyUWSession(Unknown Source)
> > at myuw.page.BasePage.setup(Unknown Source)
> > at myuw.page.Main.<init>(Unknown Source)
> > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> > Method)
> > at
> >
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> > at
> >
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> > at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
> > at
> >
> org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:173)
> > at
> >
> org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:97)
> > at
> >
> org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:47)
> > at
> >
> org.apache.wicket.DefaultMapperContext.newPageInstance(DefaultMapperContext.java:107)
> > at
> >
> org.apache.wicket.request.handler.PageProvider.resolvePageInstance(PageProvider.java:264)
> > at
> >
> org.apache.wicket.request.handler.PageProvider.getPageInstance(PageProvider.java:165)
> > at
> >
> org.apache.wicket.request.handler.ListenerInterfaceRequestHandler.getPage(ListenerInterfaceRequestHandler.java:100)
> > at
> >
> org.apache.wicket.request.handler.ListenerInterfaceRequestHandler.respond(ListenerInterfaceRequestHandler.java:165)
> >
> >
> > -----Original Message-----
> > From: Dan Retzlaff [mailto:dretzlaff@gmail.com]
> > Sent: Wednesday, December 07, 2011 4:01 PM
> > To: users@wicket.apache.org
> > Subject: Re: ConcurrentModificationException
> >
> > So it sounds like
> > 1. you've introduced a custom layer between Wicket and the servlet
> session,
> > 2. that custom layer can throw an exception called InvalidSession while
> > Wicket tries to save a page into it (during request cycle commit/detach),
> > and
> > 3. that exception gets into a handleException() method which calls
> > setResponsePage, adding a new request handler to the request cycle being
> > detached.
> >
> > If that's right, then it's probably worth mentioning that the
> commit/detach
> > phase of a request is way too late to be changing response pages. The
> best
> > you can do at that point is log an exception.
> >
> > (Apologies if I misunderstand you; it sounds fairly unconventional but
> > maybe I just haven't pieced it together correctly.)
> >
> > On Wed, Dec 7, 2011 at 3:05 PM, Fang Lin <Fa...@u.washington.edu>
> wrote:
> >
> > > That's very helpful. Thanks for sharing your code!
> > >
> > > We use a custom session manager, which verifies the session. When the
> > > underline HttpSession is expired, it throws a sub-class of
> InvalidSession
> > > exception.
> > >
> > > All the Throwable in the WebPage is handled by this method:
> > > protected void handleException(Throwable e)
> > > {
> > > if (e instanceof InvalidSession) {
> > > setResponsePage(new SessionErr()); // <== gets triggered before
> > > Wicket's PageExpiredException
> > > return;
> > > }
> > > ErrPage.logErr (getLoggerId(),
> > > e.toString(),
> > > getHttpServletRequest());
> > > if (e instanceof ParameterException) {
> > > setResponsePage(new ParamErr());
> > > return;
> > > }
> > > setResponsePage(new InternalErr());
> > > return;
> > > }
> > >
> > >
> > > public class SessionErr extends WebPage {
> > > public SessionErr ()
> > > {
> > > super ();
> > > getRequestCycle().replaceAllRequestHandlers (new
> > SessionErrHandler());
> > > }
> > > }
> > >
> > > public class SessionErrHandler extends RedirectRequestHandler {
> > > public SessionErrHandler()
> > > {
> > > super(LOG_BACKIN_URL);
> > > }
> > > }
> > >
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Dan Retzlaff [mailto:dretzlaff@gmail.com]
> > > Sent: Wednesday, December 07, 2011 1:56 PM
> > > To: users@wicket.apache.org
> > > Subject: Re: ConcurrentModificationException
> > >
> > > If you want to get to the bottom of that CME, then I'd investigate
> usage
> > #1
> > > since you've presented usages #2 and #3 and they look okay (barring a
> > > Wicket bug).
> > >
> > > In any case, I haven't been working with 1.5 very long but for what
> it's
> > > worth we have this as our custom RequestCycleListener:
> > > http://pastebin.com/SnS9PS8N
> > >
> > > Note that returning null allows Wicket to employ the registered
> > > PageExpiredErrorPage and AccessDeniedPage pages, and we set both to our
> > > Login page. The ErrorPage is our customized "oops" page for truly
> > > unexpected exceptions.
> > >
> > > On Wed, Dec 7, 2011 at 1:36 PM, Fang Lin <Fa...@u.washington.edu>
> > wrote:
> > >
> > > > Hi Dan,
> > > >
> > > >
> > > >
> > > > Thanks for the response and the question!
> > > >
> > > >
> > > >
> > > > I have put exception handler in three places:
> > > >
> > > >
> > > >
> > > > 1. In the WebPage via a try and catch
> > > >
> > > >
> > > >
> > > > 2. In the custom RequestCycleListener
> > > >
> > > >
> > > > 3. In the ApplicationSettings
> > > >
> > > >
> > > >
> > > > Because I wasn't clear about the relationship between them, I put
> them
> > > > everywhere just in case. I was also wondering why handler got invoked
> > > twice.
> > > >
> > > >
> > > >
> > > > It looks like #2 and #3 are unnecessary/redundant unless they handles
> > > > different exceptions.
> > > >
> > > > What would be the recommended approach for exception handling?
> > > >
> > > >
> > > >
> > > > -Fang
> > > >
> > > > -----Original Message-----
> > > > From: Dan Retzlaff [mailto:dretzlaff@gmail.com]
> > > > Sent: Wednesday, December 07, 2011 9:40 AM
> > > > To: users@wicket.apache.org
> > > > Subject: Re: ConcurrentModificationException
> > > >
> > > >
> > > >
> > > > 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 <Fa...@u.washington.edu>
> > > wrote:
> > > >
> > > >
> > > >
> > > > > Should I use scheduleRequestHandlerAfterCurrent instead of
> > > >
> > > > > replaceAllRequestHandlers ?
> > > >
> > > > >
> > > >
> > > > > -----Original Message-----
> > > >
> > > > > From: Fang Lin [mailto:Fanglin@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:Fanglin@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:mgrigorov@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 <Fanglin@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:mgrigorov@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 <
> Fanglin@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-unsubscribe@wicket.apache.org
> > > >
> > > > > > For additional commands, e-mail: users-help@wicket.apache.org
> > > >
> > > > > >
> > > >
> > > > >
> > > >
> > > > >
> > > >
> > > > >
> > > >
> > > > > --
> > > >
> > > > > Martin Grigorov
> > > >
> > > > > jWeekend
> > > >
> > > > > Training, Consulting, Development
> > > >
> > > > > http://jWeekend.com
> > > >
> > > > >
> > > >
> > > > >
> ---------------------------------------------------------------------
> > > >
> > > > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > >
> > > > > For additional commands, e-mail: users-help@wicket.apache.org
> > > >
> > > > >
> > > >
> > > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > For additional commands, e-mail: users-help@wicket.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
RE: ConcurrentModificationException
Posted by Fang Lin <Fa...@u.washington.edu>.
Hi Dan,
I removed the error handling logic from the WebPage and have the CustomExceptionListener handles all the Exceptions.
@Override
public IRequestHandler onException(RequestCycle cycle, Exception e)
{
logErr (cycle, e);
if (e instanceof InvalidSession) {
return new SessionErrHandler();
}
if (e instanceof GetFailedException) {
return new DbErrHandler();
}
if (e instanceof ParameterException) {
return new ParamErrHandler();
}
if (e instanceof DisallowedUwnetidException) {
return new AccessErrHandler();
}
if (e instanceof SslException) {
return new SslErrHandler();
}
return new RuntimeErrHandler();
}
Each of these handlers redirect to a static error page.
Now I get this error:
Can't instantiate page using constructor 'public myuw.page.Main(org.apache.wicket.request.mapper.parameter.PageParameters)' and argument 'f=[d], tab=[1]'. Might be it doesn't exist, may be it is not visible (public).
at org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:196)
at org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:97)
at org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:47)
at org.apache.wicket.DefaultMapperContext.newPageInstance(DefaultMapperContext.java:107)
at org.apache.wicket.request.handler.PageProvider.resolvePageInstance(PageProvider.java:264)
at org.apache.wicket.request.handler.PageProvider.getPageInstance(PageProvider.java:165)
at org.apache.wicket.request.handler.ListenerInterfaceRequestHandler.getPage(ListenerInterfaceRequestHandler.java:100)
at org.apache.wicket.request.handler.ListenerInterfaceRequestHandler.respond(ListenerInterfaceRequestHandler.java:165)
at org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:750)
at org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64)
at org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:252)
at org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:209)
at org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:280)
at org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:162)
at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:218)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
Caused by: java.lang.reflect.InvocationTargetException: null
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:173)
at org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:97)
at org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:47)
at org.apache.wicket.DefaultMapperContext.newPageInstance(DefaultMapperContext.java:107)
at org.apache.wicket.request.handler.PageProvider.resolvePageInstance(PageProvider.java:264)
at org.apache.wicket.request.handler.PageProvider.getPageInstance(PageProvider.java:165)
at org.apache.wicket.request.handler.ListenerInterfaceRequestHandler.getPage(ListenerInterfaceRequestHandler.java:100)
at org.apache.wicket.request.handler.ListenerInterfaceRequestHandler.respond(ListenerInterfaceRequestHandler.java:165)
at org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:750)
at org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64)
at org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:252)
at org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:209)
at org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:280)
at org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:162)
at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:218)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
Caused by: edu.washington.cac.myuw.servlet.session.NoExistingSessionException: An existing user but the HttpSession is null
at edu.washington.cac.myuw.servlet.session.UwSession.<init>(Unknown Source)
at myuw.sessiono.MyUWSession.<init>(Unknown Source)
at myuw.sessiono.MyUWSession.<init>(Unknown Source)
at myuw.session.MyuwSession.setMyUWSession(Unknown Source)
at myuw.page.BasePage.setMyUWSession(Unknown Source)
at myuw.page.Main.setMyUWSession(Unknown Source)
at myuw.page.BasePage.setup(Unknown Source)
at myuw.page.Main.<init>(Unknown Source)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:173)
at org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:97)
at org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:47)
at org.apache.wicket.DefaultMapperContext.newPageInstance(DefaultMapperContext.java:107)
at org.apache.wicket.request.handler.PageProvider.resolvePageInstance(PageProvider.java:264)
at org.apache.wicket.request.handler.PageProvider.getPageInstance(PageProvider.java:165)
at org.apache.wicket.request.handler.ListenerInterfaceRequestHandler.getPage(ListenerInterfaceRequestHandler.java:100)
at org.apache.wicket.request.handler.ListenerInterfaceRequestHandler.respond(ListenerInterfaceRequestHandler.java:165)
at org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:750)
-----Original Message-----
From: Fang Lin [mailto:Fanglin@u.washington.edu]
Sent: Wednesday, December 07, 2011 5:17 PM
To: 'users@wicket.apache.org'
Subject: RE: ConcurrentModificationException
Yes, that sounds like a better way as the handling logic is the same. Thanks!
Here is the stack trace when a ConcurrentModificationException occurs:
ERROR 07 17:08:51.968 setup: [m.p.BasePage] edu.washington.cac.myuw.servlet.session.NoExistingSessionException: An existing user but the HttpSession is null
at edu.washington.cac.myuw.servlet.session.UwSession.<init>(Unknown Source)
at myuw.sessiono.MyUWSession.<init>(Unknown Source)
at myuw.sessiono.MyUWSession.<init>(Unknown Source)
at myuw.session.MyuwSession.setMyUWSession(Unknown Source)
at myuw.page.BasePage.setMyUWSession(Unknown Source)
at myuw.page.BasePage.setup(Unknown Source)
at myuw.page.Main.<init>(Unknown Source)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:177)
at org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:68)
at org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:47)
at org.apache.wicket.DefaultMapperContext.newPageInstance(DefaultMapperContext.java:103)
at org.apache.wicket.request.handler.PageProvider.resolvePageInstance(PageProvider.java:264)
at org.apache.wicket.request.handler.PageProvider.getPageInstance(PageProvider.java:165)
at org.apache.wicket.request.handler.ListenerInterfaceRequestHandler.getPage(ListenerInterfaceRequestHandler.java:100)
at org.apache.wicket.request.handler.ListenerInterfaceRequestHandler.respond(ListenerInterfaceRequestHandler.java:165)
INFO 07 17:08:51.968 >>>Route to User login [m.SessionErrHandler]
ERROR 07 17:08:51.976 setup: [m.p.BasePage] edu.washington.cac.myuw.servlet.session.NoExistingSessionException: An existing user but the HttpSession is null
at edu.washington.cac.myuw.servlet.session.UwSession.<init>(Unknown Source)
at myuw.sessiono.MyUWSession.<init>(Unknown Source)
at myuw.sessiono.MyUWSession.<init>(Unknown Source)
at myuw.session.MyuwSession.setMyUWSession(Unknown Source)
at myuw.page.BasePage.setMyUWSession(Unknown Source)
at myuw.page.BasePage.setup(Unknown Source)
at myuw.page.Main.<init>(Unknown Source)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:177)
at org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:68)
at org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:47)
at org.apache.wicket.DefaultMapperContext.newPageInstance(DefaultMapperContext.java:103)
at org.apache.wicket.request.handler.PageProvider.resolvePageInstance(PageProvider.java:264)
at org.apache.wicket.request.handler.PageProvider.getPageInstance(PageProvider.java:165)
at org.apache.wicket.request.handler.PageAndComponentProvider.getComponent(PageAndComponentProvider.java:144)
at org.apache.wicket.request.handler.logger.ListenerInterfaceLogData.tryToGetComponentClass(ListenerInterfaceLogData.java:80)
INFO 07 17:08:51.976 >>>Route to User login [m.SessionErrHandler]
-----Original Message-----
From: Dan Retzlaff [mailto:dretzlaff@gmail.com]
Sent: Wednesday, December 07, 2011 4:48 PM
To: users@wicket.apache.org
Subject: Re: ConcurrentModificationException
Gotcha. Well I'm still confused, but I do have a suggestion. Instead of
catching and handling exceptions like this in your page, let them propagate
out and handle them when Wicket calls your
RequestCycleListener#onException(). No point in finishing the page
construction/rendering, right?
On Wed, Dec 7, 2011 at 4:27 PM, Fang Lin <Fa...@u.washington.edu> wrote:
> Not sure if the exception occurs at the commit/detach phase of a request.
> The session is always verified before generating the page content. See the
> stack trace:
> [m.p.BasePage]
> edu.washington.cac.myuw.servlet.session.NoExistingSessionException: An
> existing user but the HttpSession is null
> at edu.washington.cac.myuw.servlet.session.UwSession.<init>(Unknown
> Source)
> at myuw.sessiono.MyUWSession.<init>(Unknown Source)
> at myuw.session.MyuwSession.setMyUWSession(Unknown Source)
> at myuw.page.BasePage.setMyUWSession(Unknown Source)
> at myuw.page.BasePage.setup(Unknown Source)
> at myuw.page.Main.<init>(Unknown Source)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
> at
> org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:173)
> at
> org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:97)
> at
> org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:47)
> at
> org.apache.wicket.DefaultMapperContext.newPageInstance(DefaultMapperContext.java:107)
> at
> org.apache.wicket.request.handler.PageProvider.resolvePageInstance(PageProvider.java:264)
> at
> org.apache.wicket.request.handler.PageProvider.getPageInstance(PageProvider.java:165)
> at
> org.apache.wicket.request.handler.ListenerInterfaceRequestHandler.getPage(ListenerInterfaceRequestHandler.java:100)
> at
> org.apache.wicket.request.handler.ListenerInterfaceRequestHandler.respond(ListenerInterfaceRequestHandler.java:165)
>
>
> -----Original Message-----
> From: Dan Retzlaff [mailto:dretzlaff@gmail.com]
> Sent: Wednesday, December 07, 2011 4:01 PM
> To: users@wicket.apache.org
> Subject: Re: ConcurrentModificationException
>
> So it sounds like
> 1. you've introduced a custom layer between Wicket and the servlet session,
> 2. that custom layer can throw an exception called InvalidSession while
> Wicket tries to save a page into it (during request cycle commit/detach),
> and
> 3. that exception gets into a handleException() method which calls
> setResponsePage, adding a new request handler to the request cycle being
> detached.
>
> If that's right, then it's probably worth mentioning that the commit/detach
> phase of a request is way too late to be changing response pages. The best
> you can do at that point is log an exception.
>
> (Apologies if I misunderstand you; it sounds fairly unconventional but
> maybe I just haven't pieced it together correctly.)
>
> On Wed, Dec 7, 2011 at 3:05 PM, Fang Lin <Fa...@u.washington.edu> wrote:
>
> > That's very helpful. Thanks for sharing your code!
> >
> > We use a custom session manager, which verifies the session. When the
> > underline HttpSession is expired, it throws a sub-class of InvalidSession
> > exception.
> >
> > All the Throwable in the WebPage is handled by this method:
> > protected void handleException(Throwable e)
> > {
> > if (e instanceof InvalidSession) {
> > setResponsePage(new SessionErr()); // <== gets triggered before
> > Wicket's PageExpiredException
> > return;
> > }
> > ErrPage.logErr (getLoggerId(),
> > e.toString(),
> > getHttpServletRequest());
> > if (e instanceof ParameterException) {
> > setResponsePage(new ParamErr());
> > return;
> > }
> > setResponsePage(new InternalErr());
> > return;
> > }
> >
> >
> > public class SessionErr extends WebPage {
> > public SessionErr ()
> > {
> > super ();
> > getRequestCycle().replaceAllRequestHandlers (new
> SessionErrHandler());
> > }
> > }
> >
> > public class SessionErrHandler extends RedirectRequestHandler {
> > public SessionErrHandler()
> > {
> > super(LOG_BACKIN_URL);
> > }
> > }
> >
> >
> >
> >
> > -----Original Message-----
> > From: Dan Retzlaff [mailto:dretzlaff@gmail.com]
> > Sent: Wednesday, December 07, 2011 1:56 PM
> > To: users@wicket.apache.org
> > Subject: Re: ConcurrentModificationException
> >
> > If you want to get to the bottom of that CME, then I'd investigate usage
> #1
> > since you've presented usages #2 and #3 and they look okay (barring a
> > Wicket bug).
> >
> > In any case, I haven't been working with 1.5 very long but for what it's
> > worth we have this as our custom RequestCycleListener:
> > http://pastebin.com/SnS9PS8N
> >
> > Note that returning null allows Wicket to employ the registered
> > PageExpiredErrorPage and AccessDeniedPage pages, and we set both to our
> > Login page. The ErrorPage is our customized "oops" page for truly
> > unexpected exceptions.
> >
> > On Wed, Dec 7, 2011 at 1:36 PM, Fang Lin <Fa...@u.washington.edu>
> wrote:
> >
> > > Hi Dan,
> > >
> > >
> > >
> > > Thanks for the response and the question!
> > >
> > >
> > >
> > > I have put exception handler in three places:
> > >
> > >
> > >
> > > 1. In the WebPage via a try and catch
> > >
> > >
> > >
> > > 2. In the custom RequestCycleListener
> > >
> > >
> > > 3. In the ApplicationSettings
> > >
> > >
> > >
> > > Because I wasn't clear about the relationship between them, I put them
> > > everywhere just in case. I was also wondering why handler got invoked
> > twice.
> > >
> > >
> > >
> > > It looks like #2 and #3 are unnecessary/redundant unless they handles
> > > different exceptions.
> > >
> > > What would be the recommended approach for exception handling?
> > >
> > >
> > >
> > > -Fang
> > >
> > > -----Original Message-----
> > > From: Dan Retzlaff [mailto:dretzlaff@gmail.com]
> > > Sent: Wednesday, December 07, 2011 9:40 AM
> > > To: users@wicket.apache.org
> > > Subject: Re: ConcurrentModificationException
> > >
> > >
> > >
> > > 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 <Fa...@u.washington.edu>
> > wrote:
> > >
> > >
> > >
> > > > Should I use scheduleRequestHandlerAfterCurrent instead of
> > >
> > > > replaceAllRequestHandlers ?
> > >
> > > >
> > >
> > > > -----Original Message-----
> > >
> > > > From: Fang Lin [mailto:Fanglin@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:Fanglin@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:mgrigorov@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 <Fa...@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:mgrigorov@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 <Fanglin@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-unsubscribe@wicket.apache.org
> > >
> > > > > For additional commands, e-mail: users-help@wicket.apache.org
> > >
> > > > >
> > >
> > > >
> > >
> > > >
> > >
> > > >
> > >
> > > > --
> > >
> > > > Martin Grigorov
> > >
> > > > jWeekend
> > >
> > > > Training, Consulting, Development
> > >
> > > > http://jWeekend.com
> > >
> > > >
> > >
> > > > ---------------------------------------------------------------------
> > >
> > > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > >
> > > > For additional commands, e-mail: users-help@wicket.apache.org
> > >
> > > >
> > >
> > > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: ConcurrentModificationException
Posted by Fang Lin <Fa...@u.washington.edu>.
Yes, that sounds like a better way as the handling logic is the same. Thanks!
Here is the stack trace when a ConcurrentModificationException occurs:
ERROR 07 17:08:51.968 setup: [m.p.BasePage] edu.washington.cac.myuw.servlet.session.NoExistingSessionException: An existing user but the HttpSession is null
at edu.washington.cac.myuw.servlet.session.UwSession.<init>(Unknown Source)
at myuw.sessiono.MyUWSession.<init>(Unknown Source)
at myuw.sessiono.MyUWSession.<init>(Unknown Source)
at myuw.session.MyuwSession.setMyUWSession(Unknown Source)
at myuw.page.BasePage.setMyUWSession(Unknown Source)
at myuw.page.BasePage.setup(Unknown Source)
at myuw.page.Main.<init>(Unknown Source)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:177)
at org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:68)
at org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:47)
at org.apache.wicket.DefaultMapperContext.newPageInstance(DefaultMapperContext.java:103)
at org.apache.wicket.request.handler.PageProvider.resolvePageInstance(PageProvider.java:264)
at org.apache.wicket.request.handler.PageProvider.getPageInstance(PageProvider.java:165)
at org.apache.wicket.request.handler.ListenerInterfaceRequestHandler.getPage(ListenerInterfaceRequestHandler.java:100)
at org.apache.wicket.request.handler.ListenerInterfaceRequestHandler.respond(ListenerInterfaceRequestHandler.java:165)
INFO 07 17:08:51.968 >>>Route to User login [m.SessionErrHandler]
ERROR 07 17:08:51.976 setup: [m.p.BasePage] edu.washington.cac.myuw.servlet.session.NoExistingSessionException: An existing user but the HttpSession is null
at edu.washington.cac.myuw.servlet.session.UwSession.<init>(Unknown Source)
at myuw.sessiono.MyUWSession.<init>(Unknown Source)
at myuw.sessiono.MyUWSession.<init>(Unknown Source)
at myuw.session.MyuwSession.setMyUWSession(Unknown Source)
at myuw.page.BasePage.setMyUWSession(Unknown Source)
at myuw.page.BasePage.setup(Unknown Source)
at myuw.page.Main.<init>(Unknown Source)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:177)
at org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:68)
at org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:47)
at org.apache.wicket.DefaultMapperContext.newPageInstance(DefaultMapperContext.java:103)
at org.apache.wicket.request.handler.PageProvider.resolvePageInstance(PageProvider.java:264)
at org.apache.wicket.request.handler.PageProvider.getPageInstance(PageProvider.java:165)
at org.apache.wicket.request.handler.PageAndComponentProvider.getComponent(PageAndComponentProvider.java:144)
at org.apache.wicket.request.handler.logger.ListenerInterfaceLogData.tryToGetComponentClass(ListenerInterfaceLogData.java:80)
INFO 07 17:08:51.976 >>>Route to User login [m.SessionErrHandler]
-----Original Message-----
From: Dan Retzlaff [mailto:dretzlaff@gmail.com]
Sent: Wednesday, December 07, 2011 4:48 PM
To: users@wicket.apache.org
Subject: Re: ConcurrentModificationException
Gotcha. Well I'm still confused, but I do have a suggestion. Instead of
catching and handling exceptions like this in your page, let them propagate
out and handle them when Wicket calls your
RequestCycleListener#onException(). No point in finishing the page
construction/rendering, right?
On Wed, Dec 7, 2011 at 4:27 PM, Fang Lin <Fa...@u.washington.edu> wrote:
> Not sure if the exception occurs at the commit/detach phase of a request.
> The session is always verified before generating the page content. See the
> stack trace:
> [m.p.BasePage]
> edu.washington.cac.myuw.servlet.session.NoExistingSessionException: An
> existing user but the HttpSession is null
> at edu.washington.cac.myuw.servlet.session.UwSession.<init>(Unknown
> Source)
> at myuw.sessiono.MyUWSession.<init>(Unknown Source)
> at myuw.session.MyuwSession.setMyUWSession(Unknown Source)
> at myuw.page.BasePage.setMyUWSession(Unknown Source)
> at myuw.page.BasePage.setup(Unknown Source)
> at myuw.page.Main.<init>(Unknown Source)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
> at
> org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:173)
> at
> org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:97)
> at
> org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:47)
> at
> org.apache.wicket.DefaultMapperContext.newPageInstance(DefaultMapperContext.java:107)
> at
> org.apache.wicket.request.handler.PageProvider.resolvePageInstance(PageProvider.java:264)
> at
> org.apache.wicket.request.handler.PageProvider.getPageInstance(PageProvider.java:165)
> at
> org.apache.wicket.request.handler.ListenerInterfaceRequestHandler.getPage(ListenerInterfaceRequestHandler.java:100)
> at
> org.apache.wicket.request.handler.ListenerInterfaceRequestHandler.respond(ListenerInterfaceRequestHandler.java:165)
>
>
> -----Original Message-----
> From: Dan Retzlaff [mailto:dretzlaff@gmail.com]
> Sent: Wednesday, December 07, 2011 4:01 PM
> To: users@wicket.apache.org
> Subject: Re: ConcurrentModificationException
>
> So it sounds like
> 1. you've introduced a custom layer between Wicket and the servlet session,
> 2. that custom layer can throw an exception called InvalidSession while
> Wicket tries to save a page into it (during request cycle commit/detach),
> and
> 3. that exception gets into a handleException() method which calls
> setResponsePage, adding a new request handler to the request cycle being
> detached.
>
> If that's right, then it's probably worth mentioning that the commit/detach
> phase of a request is way too late to be changing response pages. The best
> you can do at that point is log an exception.
>
> (Apologies if I misunderstand you; it sounds fairly unconventional but
> maybe I just haven't pieced it together correctly.)
>
> On Wed, Dec 7, 2011 at 3:05 PM, Fang Lin <Fa...@u.washington.edu> wrote:
>
> > That's very helpful. Thanks for sharing your code!
> >
> > We use a custom session manager, which verifies the session. When the
> > underline HttpSession is expired, it throws a sub-class of InvalidSession
> > exception.
> >
> > All the Throwable in the WebPage is handled by this method:
> > protected void handleException(Throwable e)
> > {
> > if (e instanceof InvalidSession) {
> > setResponsePage(new SessionErr()); // <== gets triggered before
> > Wicket's PageExpiredException
> > return;
> > }
> > ErrPage.logErr (getLoggerId(),
> > e.toString(),
> > getHttpServletRequest());
> > if (e instanceof ParameterException) {
> > setResponsePage(new ParamErr());
> > return;
> > }
> > setResponsePage(new InternalErr());
> > return;
> > }
> >
> >
> > public class SessionErr extends WebPage {
> > public SessionErr ()
> > {
> > super ();
> > getRequestCycle().replaceAllRequestHandlers (new
> SessionErrHandler());
> > }
> > }
> >
> > public class SessionErrHandler extends RedirectRequestHandler {
> > public SessionErrHandler()
> > {
> > super(LOG_BACKIN_URL);
> > }
> > }
> >
> >
> >
> >
> > -----Original Message-----
> > From: Dan Retzlaff [mailto:dretzlaff@gmail.com]
> > Sent: Wednesday, December 07, 2011 1:56 PM
> > To: users@wicket.apache.org
> > Subject: Re: ConcurrentModificationException
> >
> > If you want to get to the bottom of that CME, then I'd investigate usage
> #1
> > since you've presented usages #2 and #3 and they look okay (barring a
> > Wicket bug).
> >
> > In any case, I haven't been working with 1.5 very long but for what it's
> > worth we have this as our custom RequestCycleListener:
> > http://pastebin.com/SnS9PS8N
> >
> > Note that returning null allows Wicket to employ the registered
> > PageExpiredErrorPage and AccessDeniedPage pages, and we set both to our
> > Login page. The ErrorPage is our customized "oops" page for truly
> > unexpected exceptions.
> >
> > On Wed, Dec 7, 2011 at 1:36 PM, Fang Lin <Fa...@u.washington.edu>
> wrote:
> >
> > > Hi Dan,
> > >
> > >
> > >
> > > Thanks for the response and the question!
> > >
> > >
> > >
> > > I have put exception handler in three places:
> > >
> > >
> > >
> > > 1. In the WebPage via a try and catch
> > >
> > >
> > >
> > > 2. In the custom RequestCycleListener
> > >
> > >
> > > 3. In the ApplicationSettings
> > >
> > >
> > >
> > > Because I wasn't clear about the relationship between them, I put them
> > > everywhere just in case. I was also wondering why handler got invoked
> > twice.
> > >
> > >
> > >
> > > It looks like #2 and #3 are unnecessary/redundant unless they handles
> > > different exceptions.
> > >
> > > What would be the recommended approach for exception handling?
> > >
> > >
> > >
> > > -Fang
> > >
> > > -----Original Message-----
> > > From: Dan Retzlaff [mailto:dretzlaff@gmail.com]
> > > Sent: Wednesday, December 07, 2011 9:40 AM
> > > To: users@wicket.apache.org
> > > Subject: Re: ConcurrentModificationException
> > >
> > >
> > >
> > > 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 <Fa...@u.washington.edu>
> > wrote:
> > >
> > >
> > >
> > > > Should I use scheduleRequestHandlerAfterCurrent instead of
> > >
> > > > replaceAllRequestHandlers ?
> > >
> > > >
> > >
> > > > -----Original Message-----
> > >
> > > > From: Fang Lin [mailto:Fanglin@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:Fanglin@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:mgrigorov@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 <Fa...@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:mgrigorov@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 <Fanglin@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-unsubscribe@wicket.apache.org
> > >
> > > > > For additional commands, e-mail: users-help@wicket.apache.org
> > >
> > > > >
> > >
> > > >
> > >
> > > >
> > >
> > > >
> > >
> > > > --
> > >
> > > > Martin Grigorov
> > >
> > > > jWeekend
> > >
> > > > Training, Consulting, Development
> > >
> > > > http://jWeekend.com
> > >
> > > >
> > >
> > > > ---------------------------------------------------------------------
> > >
> > > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > >
> > > > For additional commands, e-mail: users-help@wicket.apache.org
> > >
> > > >
> > >
> > > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: ConcurrentModificationException
Posted by Dan Retzlaff <dr...@gmail.com>.
Gotcha. Well I'm still confused, but I do have a suggestion. Instead of
catching and handling exceptions like this in your page, let them propagate
out and handle them when Wicket calls your
RequestCycleListener#onException(). No point in finishing the page
construction/rendering, right?
On Wed, Dec 7, 2011 at 4:27 PM, Fang Lin <Fa...@u.washington.edu> wrote:
> Not sure if the exception occurs at the commit/detach phase of a request.
> The session is always verified before generating the page content. See the
> stack trace:
> [m.p.BasePage]
> edu.washington.cac.myuw.servlet.session.NoExistingSessionException: An
> existing user but the HttpSession is null
> at edu.washington.cac.myuw.servlet.session.UwSession.<init>(Unknown
> Source)
> at myuw.sessiono.MyUWSession.<init>(Unknown Source)
> at myuw.session.MyuwSession.setMyUWSession(Unknown Source)
> at myuw.page.BasePage.setMyUWSession(Unknown Source)
> at myuw.page.BasePage.setup(Unknown Source)
> at myuw.page.Main.<init>(Unknown Source)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
> at
> org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:173)
> at
> org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:97)
> at
> org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:47)
> at
> org.apache.wicket.DefaultMapperContext.newPageInstance(DefaultMapperContext.java:107)
> at
> org.apache.wicket.request.handler.PageProvider.resolvePageInstance(PageProvider.java:264)
> at
> org.apache.wicket.request.handler.PageProvider.getPageInstance(PageProvider.java:165)
> at
> org.apache.wicket.request.handler.ListenerInterfaceRequestHandler.getPage(ListenerInterfaceRequestHandler.java:100)
> at
> org.apache.wicket.request.handler.ListenerInterfaceRequestHandler.respond(ListenerInterfaceRequestHandler.java:165)
>
>
> -----Original Message-----
> From: Dan Retzlaff [mailto:dretzlaff@gmail.com]
> Sent: Wednesday, December 07, 2011 4:01 PM
> To: users@wicket.apache.org
> Subject: Re: ConcurrentModificationException
>
> So it sounds like
> 1. you've introduced a custom layer between Wicket and the servlet session,
> 2. that custom layer can throw an exception called InvalidSession while
> Wicket tries to save a page into it (during request cycle commit/detach),
> and
> 3. that exception gets into a handleException() method which calls
> setResponsePage, adding a new request handler to the request cycle being
> detached.
>
> If that's right, then it's probably worth mentioning that the commit/detach
> phase of a request is way too late to be changing response pages. The best
> you can do at that point is log an exception.
>
> (Apologies if I misunderstand you; it sounds fairly unconventional but
> maybe I just haven't pieced it together correctly.)
>
> On Wed, Dec 7, 2011 at 3:05 PM, Fang Lin <Fa...@u.washington.edu> wrote:
>
> > That's very helpful. Thanks for sharing your code!
> >
> > We use a custom session manager, which verifies the session. When the
> > underline HttpSession is expired, it throws a sub-class of InvalidSession
> > exception.
> >
> > All the Throwable in the WebPage is handled by this method:
> > protected void handleException(Throwable e)
> > {
> > if (e instanceof InvalidSession) {
> > setResponsePage(new SessionErr()); // <== gets triggered before
> > Wicket's PageExpiredException
> > return;
> > }
> > ErrPage.logErr (getLoggerId(),
> > e.toString(),
> > getHttpServletRequest());
> > if (e instanceof ParameterException) {
> > setResponsePage(new ParamErr());
> > return;
> > }
> > setResponsePage(new InternalErr());
> > return;
> > }
> >
> >
> > public class SessionErr extends WebPage {
> > public SessionErr ()
> > {
> > super ();
> > getRequestCycle().replaceAllRequestHandlers (new
> SessionErrHandler());
> > }
> > }
> >
> > public class SessionErrHandler extends RedirectRequestHandler {
> > public SessionErrHandler()
> > {
> > super(LOG_BACKIN_URL);
> > }
> > }
> >
> >
> >
> >
> > -----Original Message-----
> > From: Dan Retzlaff [mailto:dretzlaff@gmail.com]
> > Sent: Wednesday, December 07, 2011 1:56 PM
> > To: users@wicket.apache.org
> > Subject: Re: ConcurrentModificationException
> >
> > If you want to get to the bottom of that CME, then I'd investigate usage
> #1
> > since you've presented usages #2 and #3 and they look okay (barring a
> > Wicket bug).
> >
> > In any case, I haven't been working with 1.5 very long but for what it's
> > worth we have this as our custom RequestCycleListener:
> > http://pastebin.com/SnS9PS8N
> >
> > Note that returning null allows Wicket to employ the registered
> > PageExpiredErrorPage and AccessDeniedPage pages, and we set both to our
> > Login page. The ErrorPage is our customized "oops" page for truly
> > unexpected exceptions.
> >
> > On Wed, Dec 7, 2011 at 1:36 PM, Fang Lin <Fa...@u.washington.edu>
> wrote:
> >
> > > Hi Dan,
> > >
> > >
> > >
> > > Thanks for the response and the question!
> > >
> > >
> > >
> > > I have put exception handler in three places:
> > >
> > >
> > >
> > > 1. In the WebPage via a try and catch
> > >
> > >
> > >
> > > 2. In the custom RequestCycleListener
> > >
> > >
> > > 3. In the ApplicationSettings
> > >
> > >
> > >
> > > Because I wasn't clear about the relationship between them, I put them
> > > everywhere just in case. I was also wondering why handler got invoked
> > twice.
> > >
> > >
> > >
> > > It looks like #2 and #3 are unnecessary/redundant unless they handles
> > > different exceptions.
> > >
> > > What would be the recommended approach for exception handling?
> > >
> > >
> > >
> > > -Fang
> > >
> > > -----Original Message-----
> > > From: Dan Retzlaff [mailto:dretzlaff@gmail.com]
> > > Sent: Wednesday, December 07, 2011 9:40 AM
> > > To: users@wicket.apache.org
> > > Subject: Re: ConcurrentModificationException
> > >
> > >
> > >
> > > 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 <Fa...@u.washington.edu>
> > wrote:
> > >
> > >
> > >
> > > > Should I use scheduleRequestHandlerAfterCurrent instead of
> > >
> > > > replaceAllRequestHandlers ?
> > >
> > > >
> > >
> > > > -----Original Message-----
> > >
> > > > From: Fang Lin [mailto:Fanglin@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:Fanglin@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:mgrigorov@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 <Fa...@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:mgrigorov@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 <Fanglin@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-unsubscribe@wicket.apache.org
> > >
> > > > > For additional commands, e-mail: users-help@wicket.apache.org
> > >
> > > > >
> > >
> > > >
> > >
> > > >
> > >
> > > >
> > >
> > > > --
> > >
> > > > Martin Grigorov
> > >
> > > > jWeekend
> > >
> > > > Training, Consulting, Development
> > >
> > > > http://jWeekend.com
> > >
> > > >
> > >
> > > > ---------------------------------------------------------------------
> > >
> > > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > >
> > > > For additional commands, e-mail: users-help@wicket.apache.org
> > >
> > > >
> > >
> > > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
RE: ConcurrentModificationException
Posted by Fang Lin <Fa...@u.washington.edu>.
Not sure if the exception occurs at the commit/detach phase of a request. The session is always verified before generating the page content. See the stack trace:
[m.p.BasePage] edu.washington.cac.myuw.servlet.session.NoExistingSessionException: An existing user but the HttpSession is null
at edu.washington.cac.myuw.servlet.session.UwSession.<init>(Unknown Source)
at myuw.sessiono.MyUWSession.<init>(Unknown Source)
at myuw.session.MyuwSession.setMyUWSession(Unknown Source)
at myuw.page.BasePage.setMyUWSession(Unknown Source)
at myuw.page.BasePage.setup(Unknown Source)
at myuw.page.Main.<init>(Unknown Source)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:173)
at org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:97)
at org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:47)
at org.apache.wicket.DefaultMapperContext.newPageInstance(DefaultMapperContext.java:107)
at org.apache.wicket.request.handler.PageProvider.resolvePageInstance(PageProvider.java:264)
at org.apache.wicket.request.handler.PageProvider.getPageInstance(PageProvider.java:165)
at org.apache.wicket.request.handler.ListenerInterfaceRequestHandler.getPage(ListenerInterfaceRequestHandler.java:100)
at org.apache.wicket.request.handler.ListenerInterfaceRequestHandler.respond(ListenerInterfaceRequestHandler.java:165)
-----Original Message-----
From: Dan Retzlaff [mailto:dretzlaff@gmail.com]
Sent: Wednesday, December 07, 2011 4:01 PM
To: users@wicket.apache.org
Subject: Re: ConcurrentModificationException
So it sounds like
1. you've introduced a custom layer between Wicket and the servlet session,
2. that custom layer can throw an exception called InvalidSession while
Wicket tries to save a page into it (during request cycle commit/detach),
and
3. that exception gets into a handleException() method which calls
setResponsePage, adding a new request handler to the request cycle being
detached.
If that's right, then it's probably worth mentioning that the commit/detach
phase of a request is way too late to be changing response pages. The best
you can do at that point is log an exception.
(Apologies if I misunderstand you; it sounds fairly unconventional but
maybe I just haven't pieced it together correctly.)
On Wed, Dec 7, 2011 at 3:05 PM, Fang Lin <Fa...@u.washington.edu> wrote:
> That's very helpful. Thanks for sharing your code!
>
> We use a custom session manager, which verifies the session. When the
> underline HttpSession is expired, it throws a sub-class of InvalidSession
> exception.
>
> All the Throwable in the WebPage is handled by this method:
> protected void handleException(Throwable e)
> {
> if (e instanceof InvalidSession) {
> setResponsePage(new SessionErr()); // <== gets triggered before
> Wicket's PageExpiredException
> return;
> }
> ErrPage.logErr (getLoggerId(),
> e.toString(),
> getHttpServletRequest());
> if (e instanceof ParameterException) {
> setResponsePage(new ParamErr());
> return;
> }
> setResponsePage(new InternalErr());
> return;
> }
>
>
> public class SessionErr extends WebPage {
> public SessionErr ()
> {
> super ();
> getRequestCycle().replaceAllRequestHandlers (new SessionErrHandler());
> }
> }
>
> public class SessionErrHandler extends RedirectRequestHandler {
> public SessionErrHandler()
> {
> super(LOG_BACKIN_URL);
> }
> }
>
>
>
>
> -----Original Message-----
> From: Dan Retzlaff [mailto:dretzlaff@gmail.com]
> Sent: Wednesday, December 07, 2011 1:56 PM
> To: users@wicket.apache.org
> Subject: Re: ConcurrentModificationException
>
> If you want to get to the bottom of that CME, then I'd investigate usage #1
> since you've presented usages #2 and #3 and they look okay (barring a
> Wicket bug).
>
> In any case, I haven't been working with 1.5 very long but for what it's
> worth we have this as our custom RequestCycleListener:
> http://pastebin.com/SnS9PS8N
>
> Note that returning null allows Wicket to employ the registered
> PageExpiredErrorPage and AccessDeniedPage pages, and we set both to our
> Login page. The ErrorPage is our customized "oops" page for truly
> unexpected exceptions.
>
> On Wed, Dec 7, 2011 at 1:36 PM, Fang Lin <Fa...@u.washington.edu> wrote:
>
> > Hi Dan,
> >
> >
> >
> > Thanks for the response and the question!
> >
> >
> >
> > I have put exception handler in three places:
> >
> >
> >
> > 1. In the WebPage via a try and catch
> >
> >
> >
> > 2. In the custom RequestCycleListener
> >
> >
> > 3. In the ApplicationSettings
> >
> >
> >
> > Because I wasn't clear about the relationship between them, I put them
> > everywhere just in case. I was also wondering why handler got invoked
> twice.
> >
> >
> >
> > It looks like #2 and #3 are unnecessary/redundant unless they handles
> > different exceptions.
> >
> > What would be the recommended approach for exception handling?
> >
> >
> >
> > -Fang
> >
> > -----Original Message-----
> > From: Dan Retzlaff [mailto:dretzlaff@gmail.com]
> > Sent: Wednesday, December 07, 2011 9:40 AM
> > To: users@wicket.apache.org
> > Subject: Re: ConcurrentModificationException
> >
> >
> >
> > 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 <Fa...@u.washington.edu>
> wrote:
> >
> >
> >
> > > Should I use scheduleRequestHandlerAfterCurrent instead of
> >
> > > replaceAllRequestHandlers ?
> >
> > >
> >
> > > -----Original Message-----
> >
> > > From: Fang Lin [mailto:Fanglin@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:Fanglin@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:mgrigorov@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 <Fa...@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:mgrigorov@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 <Fa...@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-unsubscribe@wicket.apache.org
> >
> > > > For additional commands, e-mail: users-help@wicket.apache.org
> >
> > > >
> >
> > >
> >
> > >
> >
> > >
> >
> > > --
> >
> > > Martin Grigorov
> >
> > > jWeekend
> >
> > > Training, Consulting, Development
> >
> > > http://jWeekend.com
> >
> > >
> >
> > > ---------------------------------------------------------------------
> >
> > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >
> > > For additional commands, e-mail: users-help@wicket.apache.org
> >
> > >
> >
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: ConcurrentModificationException
Posted by Dan Retzlaff <dr...@gmail.com>.
So it sounds like
1. you've introduced a custom layer between Wicket and the servlet session,
2. that custom layer can throw an exception called InvalidSession while
Wicket tries to save a page into it (during request cycle commit/detach),
and
3. that exception gets into a handleException() method which calls
setResponsePage, adding a new request handler to the request cycle being
detached.
If that's right, then it's probably worth mentioning that the commit/detach
phase of a request is way too late to be changing response pages. The best
you can do at that point is log an exception.
(Apologies if I misunderstand you; it sounds fairly unconventional but
maybe I just haven't pieced it together correctly.)
On Wed, Dec 7, 2011 at 3:05 PM, Fang Lin <Fa...@u.washington.edu> wrote:
> That's very helpful. Thanks for sharing your code!
>
> We use a custom session manager, which verifies the session. When the
> underline HttpSession is expired, it throws a sub-class of InvalidSession
> exception.
>
> All the Throwable in the WebPage is handled by this method:
> protected void handleException(Throwable e)
> {
> if (e instanceof InvalidSession) {
> setResponsePage(new SessionErr()); // <== gets triggered before
> Wicket's PageExpiredException
> return;
> }
> ErrPage.logErr (getLoggerId(),
> e.toString(),
> getHttpServletRequest());
> if (e instanceof ParameterException) {
> setResponsePage(new ParamErr());
> return;
> }
> setResponsePage(new InternalErr());
> return;
> }
>
>
> public class SessionErr extends WebPage {
> public SessionErr ()
> {
> super ();
> getRequestCycle().replaceAllRequestHandlers (new SessionErrHandler());
> }
> }
>
> public class SessionErrHandler extends RedirectRequestHandler {
> public SessionErrHandler()
> {
> super(LOG_BACKIN_URL);
> }
> }
>
>
>
>
> -----Original Message-----
> From: Dan Retzlaff [mailto:dretzlaff@gmail.com]
> Sent: Wednesday, December 07, 2011 1:56 PM
> To: users@wicket.apache.org
> Subject: Re: ConcurrentModificationException
>
> If you want to get to the bottom of that CME, then I'd investigate usage #1
> since you've presented usages #2 and #3 and they look okay (barring a
> Wicket bug).
>
> In any case, I haven't been working with 1.5 very long but for what it's
> worth we have this as our custom RequestCycleListener:
> http://pastebin.com/SnS9PS8N
>
> Note that returning null allows Wicket to employ the registered
> PageExpiredErrorPage and AccessDeniedPage pages, and we set both to our
> Login page. The ErrorPage is our customized "oops" page for truly
> unexpected exceptions.
>
> On Wed, Dec 7, 2011 at 1:36 PM, Fang Lin <Fa...@u.washington.edu> wrote:
>
> > Hi Dan,
> >
> >
> >
> > Thanks for the response and the question!
> >
> >
> >
> > I have put exception handler in three places:
> >
> >
> >
> > 1. In the WebPage via a try and catch
> >
> >
> >
> > 2. In the custom RequestCycleListener
> >
> >
> > 3. In the ApplicationSettings
> >
> >
> >
> > Because I wasn't clear about the relationship between them, I put them
> > everywhere just in case. I was also wondering why handler got invoked
> twice.
> >
> >
> >
> > It looks like #2 and #3 are unnecessary/redundant unless they handles
> > different exceptions.
> >
> > What would be the recommended approach for exception handling?
> >
> >
> >
> > -Fang
> >
> > -----Original Message-----
> > From: Dan Retzlaff [mailto:dretzlaff@gmail.com]
> > Sent: Wednesday, December 07, 2011 9:40 AM
> > To: users@wicket.apache.org
> > Subject: Re: ConcurrentModificationException
> >
> >
> >
> > 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 <Fa...@u.washington.edu>
> wrote:
> >
> >
> >
> > > Should I use scheduleRequestHandlerAfterCurrent instead of
> >
> > > replaceAllRequestHandlers ?
> >
> > >
> >
> > > -----Original Message-----
> >
> > > From: Fang Lin [mailto:Fanglin@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:Fanglin@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:mgrigorov@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 <Fa...@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:mgrigorov@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 <Fa...@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-unsubscribe@wicket.apache.org
> >
> > > > For additional commands, e-mail: users-help@wicket.apache.org
> >
> > > >
> >
> > >
> >
> > >
> >
> > >
> >
> > > --
> >
> > > Martin Grigorov
> >
> > > jWeekend
> >
> > > Training, Consulting, Development
> >
> > > http://jWeekend.com
> >
> > >
> >
> > > ---------------------------------------------------------------------
> >
> > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >
> > > For additional commands, e-mail: users-help@wicket.apache.org
> >
> > >
> >
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
RE: ConcurrentModificationException
Posted by Fang Lin <Fa...@u.washington.edu>.
That's very helpful. Thanks for sharing your code!
We use a custom session manager, which verifies the session. When the underline HttpSession is expired, it throws a sub-class of InvalidSession exception.
All the Throwable in the WebPage is handled by this method:
protected void handleException(Throwable e)
{
if (e instanceof InvalidSession) {
setResponsePage(new SessionErr()); // <== gets triggered before Wicket's PageExpiredException
return;
}
ErrPage.logErr (getLoggerId(),
e.toString(),
getHttpServletRequest());
if (e instanceof ParameterException) {
setResponsePage(new ParamErr());
return;
}
setResponsePage(new InternalErr());
return;
}
public class SessionErr extends WebPage {
public SessionErr ()
{
super ();
getRequestCycle().replaceAllRequestHandlers (new SessionErrHandler());
}
}
public class SessionErrHandler extends RedirectRequestHandler {
public SessionErrHandler()
{
super(LOG_BACKIN_URL);
}
}
-----Original Message-----
From: Dan Retzlaff [mailto:dretzlaff@gmail.com]
Sent: Wednesday, December 07, 2011 1:56 PM
To: users@wicket.apache.org
Subject: Re: ConcurrentModificationException
If you want to get to the bottom of that CME, then I'd investigate usage #1
since you've presented usages #2 and #3 and they look okay (barring a
Wicket bug).
In any case, I haven't been working with 1.5 very long but for what it's
worth we have this as our custom RequestCycleListener:
http://pastebin.com/SnS9PS8N
Note that returning null allows Wicket to employ the registered
PageExpiredErrorPage and AccessDeniedPage pages, and we set both to our
Login page. The ErrorPage is our customized "oops" page for truly
unexpected exceptions.
On Wed, Dec 7, 2011 at 1:36 PM, Fang Lin <Fa...@u.washington.edu> wrote:
> Hi Dan,
>
>
>
> Thanks for the response and the question!
>
>
>
> I have put exception handler in three places:
>
>
>
> 1. In the WebPage via a try and catch
>
>
>
> 2. In the custom RequestCycleListener
>
>
> 3. In the ApplicationSettings
>
>
>
> Because I wasn't clear about the relationship between them, I put them
> everywhere just in case. I was also wondering why handler got invoked twice.
>
>
>
> It looks like #2 and #3 are unnecessary/redundant unless they handles
> different exceptions.
>
> What would be the recommended approach for exception handling?
>
>
>
> -Fang
>
> -----Original Message-----
> From: Dan Retzlaff [mailto:dretzlaff@gmail.com]
> Sent: Wednesday, December 07, 2011 9:40 AM
> To: users@wicket.apache.org
> Subject: Re: ConcurrentModificationException
>
>
>
> 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 <Fa...@u.washington.edu> wrote:
>
>
>
> > Should I use scheduleRequestHandlerAfterCurrent instead of
>
> > replaceAllRequestHandlers ?
>
> >
>
> > -----Original Message-----
>
> > From: Fang Lin [mailto:Fanglin@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:Fanglin@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:mgrigorov@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 <Fa...@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:mgrigorov@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 <Fa...@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-unsubscribe@wicket.apache.org
>
> > > For additional commands, e-mail: users-help@wicket.apache.org
>
> > >
>
> >
>
> >
>
> >
>
> > --
>
> > Martin Grigorov
>
> > jWeekend
>
> > Training, Consulting, Development
>
> > http://jWeekend.com
>
> >
>
> > ---------------------------------------------------------------------
>
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>
> > For additional commands, e-mail: users-help@wicket.apache.org
>
> >
>
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: ConcurrentModificationException
Posted by Dan Retzlaff <dr...@gmail.com>.
If you want to get to the bottom of that CME, then I'd investigate usage #1
since you've presented usages #2 and #3 and they look okay (barring a
Wicket bug).
In any case, I haven't been working with 1.5 very long but for what it's
worth we have this as our custom RequestCycleListener:
http://pastebin.com/SnS9PS8N
Note that returning null allows Wicket to employ the registered
PageExpiredErrorPage and AccessDeniedPage pages, and we set both to our
Login page. The ErrorPage is our customized "oops" page for truly
unexpected exceptions.
On Wed, Dec 7, 2011 at 1:36 PM, Fang Lin <Fa...@u.washington.edu> wrote:
> Hi Dan,
>
>
>
> Thanks for the response and the question!
>
>
>
> I have put exception handler in three places:
>
>
>
> 1. In the WebPage via a try and catch
>
>
>
> 2. In the custom RequestCycleListener
>
>
> 3. In the ApplicationSettings
>
>
>
> Because I wasn't clear about the relationship between them, I put them
> everywhere just in case. I was also wondering why handler got invoked twice.
>
>
>
> It looks like #2 and #3 are unnecessary/redundant unless they handles
> different exceptions.
>
> What would be the recommended approach for exception handling?
>
>
>
> -Fang
>
> -----Original Message-----
> From: Dan Retzlaff [mailto:dretzlaff@gmail.com]
> Sent: Wednesday, December 07, 2011 9:40 AM
> To: users@wicket.apache.org
> Subject: Re: ConcurrentModificationException
>
>
>
> 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 <Fa...@u.washington.edu> wrote:
>
>
>
> > Should I use scheduleRequestHandlerAfterCurrent instead of
>
> > replaceAllRequestHandlers ?
>
> >
>
> > -----Original Message-----
>
> > From: Fang Lin [mailto:Fanglin@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:Fanglin@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:mgrigorov@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 <Fa...@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:mgrigorov@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 <Fa...@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-unsubscribe@wicket.apache.org
>
> > > For additional commands, e-mail: users-help@wicket.apache.org
>
> > >
>
> >
>
> >
>
> >
>
> > --
>
> > Martin Grigorov
>
> > jWeekend
>
> > Training, Consulting, Development
>
> > http://jWeekend.com
>
> >
>
> > ---------------------------------------------------------------------
>
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>
> > For additional commands, e-mail: users-help@wicket.apache.org
>
> >
>
> >
>
RE: ConcurrentModificationException
Posted by Fang Lin <Fa...@u.washington.edu>.
Hi Dan,
Thanks for the response and the question!
I have put exception handler in three places:
1. In the WebPage via a try and catch
2. In the custom RequestCycleListener
3. In the ApplicationSettings
Because I wasn't clear about the relationship between them, I put them everywhere just in case. I was also wondering why handler got invoked twice.
It looks like #2 and #3 are unnecessary/redundant unless they handles different exceptions.
What would be the recommended approach for exception handling?
-Fang
-----Original Message-----
From: Dan Retzlaff [mailto:dretzlaff@gmail.com]
Sent: Wednesday, December 07, 2011 9:40 AM
To: users@wicket.apache.org
Subject: Re: ConcurrentModificationException
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 <Fa...@u.washington.edu> wrote:
> Should I use scheduleRequestHandlerAfterCurrent instead of
> replaceAllRequestHandlers ?
>
> -----Original Message-----
> From: Fang Lin [mailto:Fanglin@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:Fanglin@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:mgrigorov@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 <Fa...@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:mgrigorov@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 <Fa...@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-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
>
>
>
> --
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: ConcurrentModificationException
Posted by Dan Retzlaff <dr...@gmail.com>.
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 <Fa...@u.washington.edu> wrote:
> Should I use scheduleRequestHandlerAfterCurrent instead of
> replaceAllRequestHandlers ?
>
> -----Original Message-----
> From: Fang Lin [mailto:Fanglin@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:Fanglin@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:mgrigorov@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 <Fa...@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:mgrigorov@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 <Fa...@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-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
>
>
>
> --
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
RE: ConcurrentModificationException
Posted by Fang Lin <Fa...@u.washington.edu>.
Should I use scheduleRequestHandlerAfterCurrent instead of replaceAllRequestHandlers ?
-----Original Message-----
From: Fang Lin [mailto:Fanglin@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:Fanglin@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:mgrigorov@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 <Fa...@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:mgrigorov@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 <Fa...@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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: ConcurrentModificationException
Posted by Fang Lin <Fa...@u.washington.edu>.
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:Fanglin@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:mgrigorov@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 <Fa...@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:mgrigorov@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 <Fa...@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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: ConcurrentModificationException
Posted by Fang Lin <Fa...@u.washington.edu>.
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:mgrigorov@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 <Fa...@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:mgrigorov@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 <Fa...@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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: ConcurrentModificationException
Posted by Martin Grigorov <mg...@apache.org>.
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 <Fa...@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:mgrigorov@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 <Fa...@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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: ConcurrentModificationException
Posted by Fang Lin <Fa...@u.washington.edu>.
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:mgrigorov@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 <Fa...@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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: ConcurrentModificationException
Posted by Martin Grigorov <mg...@apache.org>.
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 <Fa...@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: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)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.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.java:703)
> at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:896)
> at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org