Bug #7515
Synchronization uses stale nodelist when establishing new MN client connections
100%
Description
NodeCommObjectListHarvestFactory began using D1Client.getMN(mnNodeId) - get the MNode by NodeReference
rather than D1Client.getMN(mnNode.getBaseURL()) - get the MNode by BaseURL
during the upgrade to V2.
Using the NodeReference relies on a statically cached nodeList initialzed by the first call to D1Client.
Using the BaseURL constructs a new MNode regardless of the cached nodeList.
Related issues
Associated revisions
fixes #7515. replaced D1Client.getMN(NodeId) with D1Client.getMN(basUrl), because the static NodeList in D1Client can get stale.
fixes #7515. replaced D1Client.getMN(NodeId) with D1Client.getMN(basUrl), because the static NodeList in D1Client can get stale.
fixes #7515. replaced D1Client.getMN(NodeId) with D1Client.getMN(basUrl), because the static NodeList in D1Client can get stale.
fixes #7515. replaced D1Client.getMN(NodeId) with D1Client.getMN(basUrl), because the static NodeList in D1Client can get stale.
History
#1 Updated by Rob Nahf about 9 years ago
refactored the synchronization code to avoid having D1Client dereference the MemberNode, since we already have the Node object via direct call to the LDAP tables via NodeRegistryQueryService.
using D1Client.getMNode(String baseUrl) instead. It will side step the stale NodeList issue.
Caveat: submitting a bug for D1Client not having adequate support for refreshing nodeLists. It does have the method D1Client.setNodeLocator() that supports refresh, but auto-refresh is not built in.
#2 Updated by Rob Nahf about 9 years ago
- Related to Bug #7523: D1Client no longer updates stale NodeList added
#3 Updated by Rob Nahf about 9 years ago
- Status changed from New to Closed
- % Done changed from 0 to 100
Applied in changeset d1-python:d1_python|r17137.
