[YANGTOOLS-189] Java Synchronization issues in URLSchemaContextResolver Created: 16/Jun/14 Updated: 10/Apr/22 Due: 20/Jun/14 Resolved: 02/Jul/14 |
|
| Status: | Resolved |
| Project: | yangtools |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | ||
| Reporter: | Devin Avery | Assignee: | Tomas Olvecky |
| 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: | 1198 |
| Description |
|
There are some synchronization issues in the URLSchemaContextResolver class, specifically visibility issues. Specifically: The currentSchemaContext variable in this class is not thread safe. The "tryToUpdateSchemaContext" method is synchronized, but other places where we read the variable are not synchronized. This leads to "visibility" issues where an update to the variable may not be immediately visible in other threads. To fix this, we need to either make the variable currentSchemaContext volatile, or ensure that all access to it is synchronized. This can lead to indeterminate behavior. |
| Comments |
| Comment by Robert Varga [ 16/Jun/14 ] |
|
Agreed on non-safety. While a volatile may be a quickfix, the entire class is in need of complete redesign, making it very similar to the recent NotificationBroker rework: currentSourceContext and currentSchemaContext need to change atomically, which implies another level of encapsulation. While estimating the redesign, about 4-6 weeks back, I came to the conclusion that the APIs involved are not properly documented to make proper job of it, though. |
| Comment by Tomas Olvecky [ 20/Jun/14 ] |