It seems like this code results in a deadlock:

public void onDataChanged(DataChangeEvent<InstanceIdentifier<?>, DataObject> change) {
DataModification<InstanceIdentifier<?>, DataObject> tx = dataBroker.beginTransaction();
...
tx.commit().get();
}

Which suggests that the call to commit() does not defer the execution to a separate thread (or thread pool), but wants to execute it on the caller thread. Despite the fact that commit() returns a Future, which suggests it to be async.

I understand that I can work around this by manipulating threads on my own (explicitly spawning, JDKFutures, etc.).

However, I believe the current behavior is against the "principle of least astonishment", and should be fixed. Or if this is the designed behavior, it should be clearly documented.

Use the attached bundle to reproduce. Once the system is stable, execute ./runme, which will trigger the data change event. That in turn will start a new transaction, and wait for it's result...

Also see this thread on the topic:
https://lists.opendaylight.org/pipermail/controller-dev/2014-April/003556.html