java.util.ConcurrentModificationException (UidlWriter.write)

Vaadin 6 / 7 / 8
1

Hello Vaadin Experts,

I have a strange error that we have been seeing in our Vaadin application (7.5.8, Tomcat 8.0.26, Polling mode) on a particular screen. We can reproduce this error every time. After a couple of actions in the user interface, we get the following error:

[b]

2015-11-02 10:44:53,993 CST ERROR [DXOPUIServlet:service()]
 - java.util.ConcurrentModificationException:
at java.util.HashMap$HashIterator.nextNode(Unknown Source)
at java.util.HashMap$KeyIterator.next(Unknown Source)
at com.vaadin.server.communication.UidlWriter.write(UidlWriter.java:95)
at com.vaadin.server.communication.UidlRequestHandler.writeUidl(UidlRequestHandler.java:155)
at com.vaadin.server.communication.UidlRequestHandler.synchronizedHandleRequest(UidlRequestHandler.java:101)
at com.vaadin.server.SynchronizedRequestHandler.handleRequest(SynchronizedRequestHandler.java:41)
at com.vaadin.server.VaadinService.handleRequest(VaadinService.java:1408)
at com.vaadin.server.VaadinServlet.service(VaadinServlet.java:351)
at com.dmb.ui.DXOPUIServlet.service(DXOPUIServlet.java:193)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:291)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:219)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:106)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:142)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)
at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:616)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:518)
at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1091)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:673)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1526)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1482)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Unknown Source)

[/b]
Do you guys have any ideas how we can debug this further, or what might be causing this behavior?

2

Hi Cboyd,

I find your
at com.dmb.ui.DXOPUIServlet.service(DXOPUIServlet.java:193)
somewhat suspect.

From the HttpServlet documentation at https://tomcat.apache.org/tomcat-5.5-doc/servletapi/javax/servlet/http/HttpServlet.html :
There’s almost no reason to override the service method. service handles standard HTTP requests by dispatching them to the handler methods for each HTTP request type (the doXXX methods listed above).

So I wonder whether you made a mistake in that method, for example calling super() twice or not
locking access to resources where due.

3

Here is our service implementation:

    @Override
    protected void service( HttpServletRequest request, HttpServletResponse response )
        throws ServletException, IOException
    {
        VAADIN_COMM_COUNT_MAP.put( new Object(), 0 );
        try
        {
            NDC.push( CLASS_NAME + ":service()" );
            super.service( request, response );
            logger.debug( "Service Request: " + request.getQueryString() );
        }
        catch ( Exception exc )
        {
            logger.error( exc );
        }
        finally
        {
            NDC.pop();
        }
    }

I actually found that a Vaadin add-on, LazyLoadWrapper, was causing this behavior. After taking the add-on out, the behavior went away.

I do have to question why a
ConcurrentHashMap
 isn’t being used in UidlWriter though.

4

UidlWriter is designed to only be used when the VaadinSession is locked by the current thread. Chaning it to use ConcurrentHashMap would just make the issue appear in some other part that is also designed for single threaded use.

Please see
https://vaadin.com/forum#!/thread/11502121
 for more details about this kind of problem.