[CONTROLLER-1482] Missing notification request after registration Created: 05/Feb/16 Updated: 18/Feb/16 Resolved: 18/Feb/16 |
|
| Status: | Resolved |
| Project: | controller |
| Component/s: | clustering |
| Affects Version/s: | Beryllium |
| Fix Version/s: | None |
| Type: | Bug | ||
| Reporter: | Vaclav Demcak | Assignee: | Robert Varga |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Operating System: All |
||
| Issue Links: |
|
||||||||
| External issue ID: | 5247 | ||||||||
| Description |
|
OwnershipService.registerCandidate method doesn't send notification for slave role. New registered candidate has state "unknown", so getting master or slave role is a change which has to be propagated. |
| Comments |
| Comment by Robert Varga [ 05/Feb/16 ] |
|
This essentially boils down to the API contract of EntityOwnershipService, which seems to imply that a EntityOwnershipListener is not notified of the current state of the entity. A user wishing to attach a candidate, has to synchronize around calls to registerListener(), which then has to be followed-up with getOwnershipState() within the same synchronized block. This lock has to be taken by the listener, too, to prevent races. |
| Comment by Robert Varga [ 05/Feb/16 ] |
|
The problem with the above solution is that getOwnershipState() is synchronous, with no upper bound on time. This makes using it in a constrained environment, such as Netty thread callback, a very risky proposition. |
| Comment by Robert Varga [ 05/Feb/16 ] |