Boris,
Thanks for your review. Responses are inline.
>> I think we also need MetadataStorage one (details may be worked out
later) to hide the locality storage implementation details.
- Agree, my initial proposal had LocalityManager interface which
was logically similar to MetaDataStore. Changed the interface name to
MetadataStore and updated it everywhere in the proposal.
>> Instead of using physical hostname we should stick to the
LocationId, since some VMs may be running multiple processors on a single
physical host.
- Agree. This is taken into account and we have a pluggable
abstraction to generate it for different execution environments.
>> I think, though, using function names doesn't give enough clarity on
what is going on. May be we should add more explanation.
- Updated the proposal based upon this comment.
>> First diagram describes how local storage works. Please label it as
such.
- Updated the proposal to address this comment.
>> Some time the perfect mapping to the same Locality is not
possible(especially when a task dies and is distributed between other
tasks).
- Yes, this is worst case scenario where the task will be
assigned to any processor when there’re no live processors registered from
it’s preferred host.
Thanks.
