Any ResourceHandler would be concurrently accessed by different user's lifecycles, so should hold all state either in a method's scope, or if state needs to transcend lifecycles, then hold it in the appropriate Flash/FacesContext/Session/Application map.

Attached full error stack trace

Just adding my comments from the email thread:

ResourceHandlers need to be thread-safe (as per the JavaDoc) as I believe there is only one instance of each handler per application so multiple threads could potentially get in there.

The problem seems to be that, inside the constructor of our InputRichTextResourceHandler, we register to listen for PreRenderViewEvent. Multiple clients can trigger this handler so multiple events could be arriving at any given time (for each view about to rendered). Inside our handler for this event, we take some of our collections (allResources, imageResources, cssResources) and calculate the mappings during the first request. However, neither the methods nor the collections themselves are thread-safe and during calculation of the mappings we iterate over all of them.

Since these mappings don't need to be calculated more than once (keeping portlets in mind), then, as Mark noted above, maybe we should either be storing the collections (or just a flag) in the appropriate scope indicating that the calculations have been done.

The first effort consists in modifying the resource handling process, so that the resources don't have to be mapped dynamically while the application is running. The resources are now being mapped statically, using #resource expressions, so that the server only has to convert such expressions to actual URLs, without having to calculate the mappings at each request. This is the same idea of ICE-8715 with ace:richTextEntry.

Committed new approach to serve CKEditor resources at revision 37245 in the trunk and at revision 37246 in the p01 tag.

Now, resource mappings are not calculated dynamically when the app is deployed. Instead, there's a static ckeditor.mappings.js resource that contains resource expressions, which the new resource handler interprets in the same way as with CSS resources. The resource handler class now doesn't keep much state: only a reference to the wrapped object and a reference to the resource object.

With the new approach, there are no collections or other objects that could potentially be concurrently modified by different threads, so that alone prevents concurrent modification exceptions. The only instance variable of the resource handler is the resource object itself, which is simply registered at the first request, without any further processing. Once this resource is registered, the instance variable is not null, and future threads will check for null and avoid re-registering this resource. Just to make things more robust, the line where this instance variable is checked for null was enclosed in a synchronized statement, in order to completely prevent registering this resource multiple times under extreme circumstances.

This was committed at revision 37247 to the trunk and at revision 37248 to the p01 tag.

Is this patch already included in the current snapshot for version 3.4? I am asking because I still see this exception from time to time when starting parallel selenium tests.

Please attach an exception stack trace.

Thank you, that does look like this specific issue. Are you running code from after subversion 37247? That's the revision where this fix should be complete.

I am using the current snapshot version (compat-3.4.0-20130723.214239-4 and the other artifacts build from this day respectivelly) that is available at http://anonsvn.icesoft.org/repo/maven2/snapshots/org/icefaces/. Unfortunately I have no clue, if revision 37247 has been incorporated into the build, but from the heading when surfing this URL it seems to me as if this is the right build.

It looks like the version you have is from July 23rd, and the fix was complete on July 26, so no I don't believe you have the fix.

That would explain the exception - thanks for checking and sorry for the inconvenience. Isn't building the snapshot version triggered by commits on a - let's say daily or weekly basis? So I am curious, when the patched version will be available in the repo. Anyway - great work guys. Keep on...