[CONTROLLER-636] Deadlock scenario with DataChangeListeners Created: 17/Jul/14 Updated: 07/Aug/14 Resolved: 07/Aug/14 |
|
| Status: | Resolved |
| Project: | controller |
| Component/s: | mdsal |
| Affects Version/s: | Helium |
| Fix Version/s: | None |
| Type: | Bug | ||
| Reporter: | Tom Pantelis | Assignee: | Tom Pantelis |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Operating System: All |
||
| External issue ID: | 1386 |
| Priority: | High |
| Description |
|
There is a deadlock scenario with DataChangeListeners if they commit a write transaction and call get() on the Future to synchronously wait for the response, as in the following code. public void onDataChanged( ... ) { ... WriteTransaction tx = dataBroker.newWriteOnlyTransaction( ... ); tx.submit().get(); // blocking call }If the code handled the Future async via a FutureCallback then there wouldn't be an issue. The reason is that a shared single-threaded executor is used to perform commits and notify DataChangeListeners. The single-threaded nature of commits and notifications will be looked at further at some point but, in the mean time, we can at least detect this situation and throw an exception to avoid deadlock. We can use a ThreadLocal variable that is set in the commit/notification thread. We can subclass the returned Future and, When get() is called, check if the ThreadLocal is set and, if so, set an exception in the Future. |
| Comments |
| Comment by Tom Pantelis [ 17/Jul/14 ] |