ListSelect/TwinColSelect get A connector should not be marked as dirty whil

Vaadin 6 / 7 / 8
1

I am trying to load either a ListSelect or a TwinColSelect componet with a SQLContainer. When I run the application I get the following error.

A connector should not be marked as dirty while a response is being written

I know this was an issue in the past. What is the work around or fix?
I am using Vaadin 7.2.6

Here is the complete error message:
Aug 21, 2014 6:47:04 PM com.vaadin.server.DefaultErrorHandler doDefault
SEVERE:
java.lang.IllegalStateException: A connector should not be marked as dirty while a response is being written.
at com.vaadin.ui.ConnectorTracker.markDirty(ConnectorTracker.java:412)
at com.vaadin.server.AbstractClientConnector.markAsDirty(AbstractClientConnector.java:138)
at com.vaadin.ui.AbstractSelect.fireItemSetChange(AbstractSelect.java:1710)
at com.vaadin.ui.AbstractSelect.containerItemSetChange(AbstractSelect.java:1677)
at com.vaadin.data.util.sqlcontainer.SQLContainer.fireContentsChange(SQLContainer.java:1626)
at com.vaadin.data.util.sqlcontainer.SQLContainer.refresh(SQLContainer.java:911)
at com.vaadin.data.util.sqlcontainer.SQLContainer.updateCount(SQLContainer.java:1169)
at com.vaadin.data.util.sqlcontainer.SQLContainer.getItemIds(SQLContainer.java:331)
at com.vaadin.ui.AbstractSelect.getItemIds(AbstractSelect.java:728)
at com.vaadin.ui.AbstractSelect.paintContent(AbstractSelect.java:367)
at com.vaadin.ui.ListSelect.paintContent(ListSelect.java:124)
at com.vaadin.server.LegacyPaint.paint(LegacyPaint.java:65)
at com.vaadin.server.communication.LegacyUidlWriter.write(LegacyUidlWriter.java:82)
at com.vaadin.server.communication.UidlWriter.write(UidlWriter.java:120)
at com.vaadin.server.communication.UidlRequestHandler.writeUidl(UidlRequestHandler.java:151)
at com.vaadin.server.communication.UidlRequestHandler.synchronizedHandleRequest(UidlRequestHandler.java:99)
at com.vaadin.server.SynchronizedRequestHandler.handleRequest(SynchronizedRequestHandler.java:41)
at com.vaadin.server.VaadinService.handleRequest(VaadinService.java:1401)
at com.vaadin.server.VaadinServlet.service(VaadinServlet.java:237)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:728)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:51)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:953)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1041)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:603)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:312)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

2

That does look like a bug, but manually calling container.getItemIds() should get rid of the error since the container caches the results for 10 seconds.

I’ll report the issue, thanks.

3

The issue has been marked a duplicate of
http://dev.vaadin.com/ticket/12085
 which I have commented on extensiveley (as avebo42). My patch attached there still works for me (last tested with Vaadin 7.2.6), although thinking about it, there might be another workaround.

Recap: This problem only arises when a component that inherits from AbstractSelect has a Container bound during construction that then calls markDirty. SQLContainer (for example) does that, since its getItemIds method gets called, which causes it to load the items from the DB, and then to call fireContentsChange. Some of the selection components (like Table and ComboBox) have been ‘fixed’ against this already via keeping an ‘inPainting’ flag, and ignoring markDirty if it is set. All remaining components (like TwinColSelect) cause a java.lang.IllegalStateException in this situation.

I assume (not tested!) that you could try not to bind the Container to the control in the constructor, and instead bind it in View::enter(). Unfortunately most Vaadin samples I’ve seen bind the Container in the constructUI method which is called in the constructor.

It’s much better to bind the Container to the component when the user is about to see the data (i.e. in enter()), not only because this might avoid this bug, but also because your application might construct a lot of views when being instatiated, and each view with a bound SQLContainer will then hit the database at the same time. Also the data might be outdated once the user gets to see the view, or the container will reload it for that reason - then the first load was completely in vein.

I.e. if you bind via fieldgroup, you could construct and bind all the fields to the fieldgroup in an overridden enter() method, but only once (e.g. keep a flag, construct only on first entry).

4

Thanks a lot for this workaround, Thomas. It’s been of great help.