See issue #122257.

DataNode nodeDestroyed event is *sometimes* fired synchronously while the DataObjectPool is in 'atomic' state (its atomic variable is set to current thread). 

The code reacting in EDT to the node event in issue #122257 caused a DataEditorSupport.openDocument() call, which eventually run prepareDocument and tried to open the document in another thread B, waiting for the result. The thread B required DataObject access, but DataObject.find() blocked in enterRecognition on the atomic action not finished in EDT.

The fix in #122257 was to pre-fetch encoding in DataEditorSupport.openDocument to avoid executing the query in document loading code.

The fix contributes to issue #216679 and I think the fix could be made in a different way - the reason for the deadlock is not primarily the FEncQuery, but execution of a listener chain while DataObjectPool is in a restricted state.

A simple fix would be to offload DataNode fireNodeDestroyed to a request processor, so that the DataObject.dispose() and call above it complete, unlock the DataObjectPool. A potential thread B then can proceed with DataObjectPool access to find out document encoding and load it. The code in DataEditor.openDocument can be removed, which breaks condition leading to #216679 and may improve performance - FEQ will be run only when actually reading the stream, not when openDocument() is called on an already opened editor.

More elaborate fix would postpone the DataObject.firePropertyChange(PROP_VALID) until after the DataObjectPool.runAtomicAction completes. This could be done inside DataSystems module wihtout changing API and even without changing the thread assignment of operations as in the 1st fix alternative above. A brutal solution would be to queue all events fired from DataObject.firePropertyChange until after DataObjectPool.runAtomic completes. Still not 100% safe, since setValid and dispose() are not final and could potentially extend the DataObjectPool lock in an unexpected way.