You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by David Rees <dr...@gmail.com> on 2011/05/14 00:32:55 UTC
Re: Rather worrying exception with 5.2.4 (java.util.ConcurrentModificationException)
On Fri, Feb 4, 2011 at 7:17 AM, Ulrich Stärk <ul...@spielviel.de> wrote:
> Could you try again with tapestry-spring-security disabled?
I have seen the same stack trace in my application without
tapestry-spring-security using tapestry 5.2.5. See below.
-Dave
ERROR: 13463: org.apache.tapestry5.services.TapestryModule.RequestExceptionHandler:
Unexpected runtime exception: Unable to attach page Start (en):
java.util.ConcurrentModificationException
java.lang.RuntimeException: Unable to attach page Start (en):
java.util.ConcurrentModificationException
at org.apache.tapestry5.internal.services.NonPoolingRequestPageCacheImpl.get(NonPoolingRequestPageCacheImpl.java:82)
at $RequestPageCache_12fe8a64398.get($RequestPageCache_12fe8a64398.java)
at $RequestPageCache_12fe8a64392.get($RequestPageCache_12fe8a64392.java)
at org.apache.tapestry5.internal.services.AjaxComponentEventRequestHandler.handle(AjaxComponentEventRequestHandler.java:70)
at org.apache.tapestry5.internal.services.ajax.AjaxFormUpdateFilter.handle(AjaxFormUpdateFilter.java:56)
at $ComponentEventRequestHandler_12fe8a64747.handle($ComponentEventRequestHandler_12fe8a64747.java)
at $ComponentEventRequestHandler_12fe8a644b8.handle($ComponentEventRequestHandler_12fe8a644b8.java)
at org.apache.tapestry5.internal.services.AjaxFilter.handle(AjaxFilter.java:42)
at $ComponentEventRequestHandler_12fe8a644ba.handle($ComponentEventRequestHandler_12fe8a644ba.java)
at org.apache.tapestry5.upload.internal.services.UploadExceptionFilter.handle(UploadExceptionFilter.java:75)
at $ComponentEventRequestHandler_12fe8a644ba.handle($ComponentEventRequestHandler_12fe8a644ba.java)
at org.apache.tapestry5.services.TapestryModule$39.handle(TapestryModule.java:2583)
at $ComponentEventRequestHandler_12fe8a644ba.handle($ComponentEventRequestHandler_12fe8a644ba.java)
at $ComponentEventRequestHandler_12fe8a6438f.handle($ComponentEventRequestHandler_12fe8a6438f.java)
at org.apache.tapestry5.internal.services.ComponentRequestHandlerTerminator.handleComponentEvent(ComponentRequestHandlerTerminator.java:43)
at org.apache.tapestry5.services.InitializeActivePageName.handleComponentEvent(InitializeActivePageName.java:39)
at $ComponentRequestHandler_12fe8a64391.handleComponentEvent($ComponentRequestHandler_12fe8a64391.java)
at $ComponentRequestHandler_12fe8a64373.handleComponentEvent($ComponentRequestHandler_12fe8a64373.java)
at org.apache.tapestry5.internal.services.ComponentEventDispatcher.dispatch(ComponentEventDispatcher.java:46)
at $Dispatcher_12fe8a64377.dispatch($Dispatcher_12fe8a64377.java)
at $Dispatcher_12fe8a6436f.dispatch($Dispatcher_12fe8a6436f.java)
at org.apache.tapestry5.services.TapestryModule$RequestHandlerTerminator.service(TapestryModule.java:321)
at com.frontend.presentation.services.AppModule$1.service(AppModule.java:134)
at $RequestFilter_12fe8a6436e.service($RequestFilter_12fe8a6436e.java)
at org.apache.tapestry5.internal.services.RequestErrorFilter.service(RequestErrorFilter.java:26)
at $RequestHandler_12fe8a64370.service($RequestHandler_12fe8a64370.java)
at $RequestHandler_12fe8a64370.service($RequestHandler_12fe8a64370.java)
at org.apache.tapestry5.services.TapestryModule$4.service(TapestryModule.java:984)
at $RequestHandler_12fe8a64370.service($RequestHandler_12fe8a64370.java)
at org.apache.tapestry5.services.TapestryModule$3.service(TapestryModule.java:974)
at $RequestHandler_12fe8a64370.service($RequestHandler_12fe8a64370.java)
at org.apache.tapestry5.internal.services.StaticFilesFilter.service(StaticFilesFilter.java:90)
at $RequestHandler_12fe8a64370.service($RequestHandler_12fe8a64370.java)
at org.apache.tapestry5.internal.services.CheckForUpdatesFilter$2.invoke(CheckForUpdatesFilter.java:90)
at org.apache.tapestry5.internal.services.CheckForUpdatesFilter$2.invoke(CheckForUpdatesFilter.java:81)
at org.apache.tapestry5.ioc.internal.util.ConcurrentBarrier.withRead(ConcurrentBarrier.java:85)
at org.apache.tapestry5.internal.services.CheckForUpdatesFilter.service(CheckForUpdatesFilter.java:103)
at $RequestHandler_12fe8a64370.service($RequestHandler_12fe8a64370.java)
at $RequestHandler_12fe8a64367.service($RequestHandler_12fe8a64367.java)
at org.apache.tapestry5.services.TapestryModule$HttpServletRequestHandlerTerminator.service(TapestryModule.java:272)
at org.apache.tapestry5.upload.internal.services.MultipartServletRequestFilter.service(MultipartServletRequestFilter.java:44)
at $HttpServletRequestHandler_12fe8a64369.service($HttpServletRequestHandler_12fe8a64369.java)
at org.apache.tapestry5.internal.services.IgnoredPathsFilter.service(IgnoredPathsFilter.java:62)
at $HttpServletRequestFilter_12fe8a64366.service($HttpServletRequestFilter_12fe8a64366.java)
at $HttpServletRequestHandler_12fe8a64369.service($HttpServletRequestHandler_12fe8a64369.java)
at org.apache.tapestry5.services.TapestryModule$2.service(TapestryModule.java:928)
at $HttpServletRequestHandler_12fe8a64369.service($HttpServletRequestHandler_12fe8a64369.java)
at $HttpServletRequestHandler_12fe8a64363.service($HttpServletRequestHandler_12fe8a64363.java)
at org.apache.tapestry5.TapestryFilter.doFilter(TapestryFilter.java:147)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at com.ndcfilter.filter.NDCFilter.doFilter(NDCFilter.java:42)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:172)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
at org.apache.catalina.valves.FastCommonAccessLogValve.invoke(FastCommonAccessLogValve.java:500)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108)
at org.apache.catalina.cluster.session.JvmRouteBinderValve.invoke(JvmRouteBinderValve.java:228)
at org.apache.catalina.cluster.tcp.ReplicationValve.invoke(ReplicationValve.java:347)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:174)
at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:200)
at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:291)
at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:775)
at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:704)
at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:897)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.util.ConcurrentModificationException
at java.util.Hashtable$Enumerator.next(Hashtable.java:1031)
at org.apache.catalina.util.Enumerator.<init>(Enumerator.java:101)
at org.apache.catalina.util.Enumerator.<init>(Enumerator.java:67)
at org.apache.catalina.cluster.session.DeltaSession.getAttributeNames(DeltaSession.java:1046)
at org.apache.catalina.cluster.session.DeltaSessionFacade.getAttributeNames(DeltaSessionFacade.java:121)
at org.apache.tapestry5.internal.services.SessionImpl.getAttributeNames(SessionImpl.java:77)
at org.apache.tapestry5.internal.services.AbstractSessionPersistentFieldStrategy.gatherFieldChanges(AbstractSessionPersistentFieldStrategy.java:55)
at org.apache.tapestry5.internal.services.PersistentFieldManagerImpl.gatherChanges(PersistentFieldManagerImpl.java:62)
at $PersistentFieldManager_12fe8a643a9.gatherChanges($PersistentFieldManager_12fe8a643a9.java)
at org.apache.tapestry5.internal.structure.PageImpl.getFieldChange(PageImpl.java:206)
at org.apache.tapestry5.internal.structure.InternalComponentResourcesImpl.getFieldChange(InternalComponentResourcesImpl.java:176)
at org.apache.tapestry5.internal.structure.InternalComponentResourcesImpl.hasFieldChange(InternalComponentResourcesImpl.java:186)
at org.apache.tapestry5.internal.transform.PersistWorker$PersistentFieldConduit.restoreStateAtPageAttach(PersistWorker.java:80)
at org.apache.tapestry5.internal.transform.PersistWorker$PersistentFieldConduit.access$000(PersistWorker.java:38)
at org.apache.tapestry5.internal.transform.PersistWorker$PersistentFieldConduit$1.restoreStateBeforePageAttach(PersistWorker.java:61)
at org.apache.tapestry5.internal.structure.PageImpl.attached(PageImpl.java:184)
at org.apache.tapestry5.internal.services.NonPoolingRequestPageCacheImpl.get(NonPoolingRequestPageCacheImpl.java:78)
... 69 more
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Rather worrying exception with 5.2.4 (java.util.ConcurrentModificationException)
Posted by Josh Canfield <jo...@gmail.com>.
> I've been investigating a broader approach that identifies when
> multiple threads are operating on the same session and serializes
> those requests using a per-session lock (possibly, by synchronizing on
> the session relatively early in the pipeline)
There are times when you want your session to be accessed in parallel.
For instance, consider a private image gallery where image requests
are protected using information stored in the session.
This is the use-case that pointed out the problem with forcing cluster
updates by setting the session attributes to null briefly (causing a
new session attribute created). Forcing a multi-threaded app to run
serially seems a little drastic.
Josh
On Mon, May 16, 2011 at 5:41 PM, Howard Lewis Ship <hl...@gmail.com> wrote:
> That's a very good catch; it's difficult to do work that requires
> synchronizing the Session because locking it can also cause deadlocks.
> I've been investigating a broader approach that identifies when
> multiple threads are operating on the same session and serializes
> those requests using a per-session lock (possibly, by synchronizing on
> the session relatively early in the pipeline).
>
> On Mon, May 16, 2011 at 12:31 PM, David Rees <dr...@gmail.com> wrote:
>> On Mon, May 16, 2011 at 7:57 AM, antalk <an...@intercommit.nl> wrote:
>>> Thanks for your message, i hope it is now clear that it indeed is a issue
>>> somewhere within Tapestry. As a matter of fact i didn't saw this message for
>>> a long time on our test machines. But just today i encountered the same
>>> issue again.
>>
>> It looks like SessionImpl.getAttributeNames should be reworked to
>> synchronize on the session - or at least catch the
>> ConcurrentModificationException and try again (see patch below) which
>> is simpler.
>>
>> But I worry that the same error could be thrown in the
>> getAttributeNames function on line 61, too - similar technique should
>> probably be used there as well.
>>
>> --- SessionImpl.java~ 2011-05-16 12:19:31.159348203 -0700
>> +++ SessionImpl.java 2011-05-16 12:28:35.073307235 -0700
>> @@ -72,8 +72,27 @@
>>
>> public List<String> getAttributeNames(String prefix)
>> {
>> - List<String> result = CollectionFactory.newList();
>> + List<String> result = null;
>>
>> + do
>> + {
>> + try
>> + {
>> + result = getAttributeNamesFromSession(prefix);
>> + }
>> + catch (ConcurrentModificationException)
>> + {
>> + // Ignore - result will be null so we will try again
>> + }
>> + }
>> + while (result == null);
>> +
>> + return result;
>> + }
>> +
>> + private List<String> getAttributeNamesFromSession(String prefix)
>> throws ConcurrentModificationException
>> + {
>> + List<String> result = CollectionFactory.newList();
>> Enumeration e = session.getAttributeNames();
>> while (e.hasMoreElements())
>> {
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>>
>
>
>
> --
> Howard M. Lewis Ship
>
> Creator of Apache Tapestry
>
> The source for Tapestry training, mentoring and support. Contact me to
> learn how I can get you up and productive in Tapestry fast!
>
> (971) 678-5210
> http://howardlewisship.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Rather worrying exception with 5.2.4 (java.util.ConcurrentModificationException)
Posted by Howard Lewis Ship <hl...@gmail.com>.
That's a very good catch; it's difficult to do work that requires
synchronizing the Session because locking it can also cause deadlocks.
I've been investigating a broader approach that identifies when
multiple threads are operating on the same session and serializes
those requests using a per-session lock (possibly, by synchronizing on
the session relatively early in the pipeline).
On Mon, May 16, 2011 at 12:31 PM, David Rees <dr...@gmail.com> wrote:
> On Mon, May 16, 2011 at 7:57 AM, antalk <an...@intercommit.nl> wrote:
>> Thanks for your message, i hope it is now clear that it indeed is a issue
>> somewhere within Tapestry. As a matter of fact i didn't saw this message for
>> a long time on our test machines. But just today i encountered the same
>> issue again.
>
> It looks like SessionImpl.getAttributeNames should be reworked to
> synchronize on the session - or at least catch the
> ConcurrentModificationException and try again (see patch below) which
> is simpler.
>
> But I worry that the same error could be thrown in the
> getAttributeNames function on line 61, too - similar technique should
> probably be used there as well.
>
> --- SessionImpl.java~ 2011-05-16 12:19:31.159348203 -0700
> +++ SessionImpl.java 2011-05-16 12:28:35.073307235 -0700
> @@ -72,8 +72,27 @@
>
> public List<String> getAttributeNames(String prefix)
> {
> - List<String> result = CollectionFactory.newList();
> + List<String> result = null;
>
> + do
> + {
> + try
> + {
> + result = getAttributeNamesFromSession(prefix);
> + }
> + catch (ConcurrentModificationException)
> + {
> + // Ignore - result will be null so we will try again
> + }
> + }
> + while (result == null);
> +
> + return result;
> + }
> +
> + private List<String> getAttributeNamesFromSession(String prefix)
> throws ConcurrentModificationException
> + {
> + List<String> result = CollectionFactory.newList();
> Enumeration e = session.getAttributeNames();
> while (e.hasMoreElements())
> {
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Rather worrying exception with 5.2.4 (java.util.ConcurrentModificationException)
Posted by David Rees <dr...@gmail.com>.
On Mon, May 16, 2011 at 7:57 AM, antalk <an...@intercommit.nl> wrote:
> Thanks for your message, i hope it is now clear that it indeed is a issue
> somewhere within Tapestry. As a matter of fact i didn't saw this message for
> a long time on our test machines. But just today i encountered the same
> issue again.
It looks like SessionImpl.getAttributeNames should be reworked to
synchronize on the session - or at least catch the
ConcurrentModificationException and try again (see patch below) which
is simpler.
But I worry that the same error could be thrown in the
getAttributeNames function on line 61, too - similar technique should
probably be used there as well.
--- SessionImpl.java~ 2011-05-16 12:19:31.159348203 -0700
+++ SessionImpl.java 2011-05-16 12:28:35.073307235 -0700
@@ -72,8 +72,27 @@
public List<String> getAttributeNames(String prefix)
{
- List<String> result = CollectionFactory.newList();
+ List<String> result = null;
+ do
+ {
+ try
+ {
+ result = getAttributeNamesFromSession(prefix);
+ }
+ catch (ConcurrentModificationException)
+ {
+ // Ignore - result will be null so we will try again
+ }
+ }
+ while (result == null);
+
+ return result;
+ }
+
+ private List<String> getAttributeNamesFromSession(String prefix)
throws ConcurrentModificationException
+ {
+ List<String> result = CollectionFactory.newList();
Enumeration e = session.getAttributeNames();
while (e.hasMoreElements())
{
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Rather worrying exception with 5.2.4
(java.util.ConcurrentModificationException)
Posted by antalk <an...@intercommit.nl>.
Hi Dave,
Thanks for your message, i hope it is now clear that it indeed is a issue
somewhere within Tapestry. As a matter of fact i didn't saw this message for
a long time on our test machines. But just today i encountered the same
issue again.
It popped-up during the display of a grid where the grid contains columns
who's information is retrieved using a progressive display component,
causing multiple threads to execute to retrieve and peform page (html)
creation.
Antal
--
View this message in context: http://tapestry.1045711.n5.nabble.com/Rather-worrying-exception-with-5-2-4-java-util-ConcurrentModificationException-tp3370588p4400666.html
Sent from the Tapestry - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org