Exception: A connector should not be marked as dirty while a response is be

Hi all,

I am facing a strange problem since I switched to Vaadin 7 that I wasn’t getting previously.

I have a treetable inside a VerticalSplitPanel. The content can be big so it is loaded in a separate thread.

Sometimes, specially when loading a big amount of data, I get the following exception: “A connector should not be marked as dirty while a response is being written.”

The stacktrace is:

Exception in thread "Thread-6" 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:290)
	at com.vaadin.server.AbstractClientConnector.markAsDirty(AbstractClientConnector.java:96)
	at com.vaadin.ui.Table.markAsDirty(Table.java:1679)
	at com.vaadin.ui.AbstractSelect.fireItemSetChange(AbstractSelect.java:1642)
	at com.vaadin.ui.AbstractSelect.containerItemSetChange(AbstractSelect.java:1609)
	at com.vaadin.ui.Table.containerItemSetChange(Table.java:4102)
	at com.vaadin.ui.TreeTable.containerItemSetChange(TreeTable.java:609)
	at com.vaadin.data.util.AbstractContainer.fireItemSetChange(AbstractContainer.java:242)
	at com.vaadin.data.util.HierarchicalContainer.fireItemSetChange(HierarchicalContainer.java:425)
	at com.vaadin.data.util.IndexedContainer.fireItemSetChange(IndexedContainer.java:626)
	at com.vaadin.data.util.HierarchicalContainer.enableAndFireContentsChangeEvents(HierarchicalContainer.java:442)
	at com.vaadin.data.util.HierarchicalContainer.addItem(HierarchicalContainer.java:467)
	at com.vaadin.ui.Table.addItem(Table.java:2357)
	at dp.webadmin.ui.entityEditorView.entityEditViews.UserEditView$ContextSearch$ContextSearchTable.addContextAndUser(UserEditView.java:243)
	at dp.webadmin.ui.entityEditorView.entityEditViews.UserEditView$ContextSearch$ContextSearchTable.access$100(UserEditView.java:171)
	at dp.webadmin.ui.entityEditorView.entityEditViews.UserEditView$ContextSearch$ContextSearchTable$LoadContextRelationsThread.run(UserEditView.java:318)

I am not sure if its my fault or a bug, since this was working fine until beta1.

I think there is some kind of race condition because I could not reproduce the error by doing exactly he same thing.

Thank you in advance for your help.

Yes, the increased strictness regarding when connectors may be marked as dirty was added in beta1 to help developers pinpoint race conditions and similar issues that previously only caused unexplainable random issues if anything happened at all.

I guess the problem is that your background thread doesn’t use the new locking scheme (also added in beta1) when adding new items to the TreeTable (Table.addItem invoked at UserEditView.java:243). The proper way to protect UI state modification in background threads looks like this as of beta1:

component.getUI().getSession().getLock().lock();
try {
   doStuffWith(component);
} finally {
   component.getUI().getSession().getLock().unlock();
}

The old way of doing synchronized(application) will no longer have any effect and there is unfortunately no way of making this cause compile errors to automatically make the developer aware of the changes (aside from the fact that there isn’t any application in most apps).

In an upcoming beta, we will also make the framework automatically verify that the lock is held during certain operations if assertions are enabled, but we must first fix some edge cases in the framework where the locking is not done properly…

Thanks a lot! That was it. I guess this was probably published somewhere I didn’t read.

Keep up the good work!

It is briefly mentioned in the
Migration guide
, but considering the length and complexity of that document, I would be surprised if anyone actually read it and even more surprised if the reader would actually get everything right from reading it. :grin:

Wouldn’t this render ICEPush worthless?
Isn’t the whole point of it is to be able to modify data in the background and then sync it up?

No - this just requires a change in the application and push add-on code that performs synchronization/locking.

Built-in push support is planned (and under work) for Vaadin 7.1, that will render ICEPush unnecessary. Because of this, I would not expect many push add-ons to be ported for Vaadin 7.

Yeah, ICE is the only one I found working w/ 7.

But this was the downfall of swing: requiring making all the changes in the UI thread.
Hope vaadin reverses the death-spiral decision in 7.1.

instead, try following code:
getUI().getSession().getLockInstance();
No need to invoke lock() or unlock()

thanks, it helped :slight_smile: