-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/39331/
-----------------------------------------------------------

(Updated Nov. 11, 2015, 9:49 a.m.)


Review request for mesos, Anand Mazumdar, Jie Yu, Jojy Varghese, and Timothy 
Chen.


Bugs: MESOS-3736
    https://issues.apache.org/jira/browse/MESOS-3736


Repository: mesos


Description
-------

Support docker local store pull image simultaneously


Diffs (updated)
-----

  src/slave/containerizer/mesos/provisioner/docker/store.hpp 
95e46b9914c018b3e2472f98a54bc33ff9a46e17 
  src/slave/containerizer/mesos/provisioner/docker/store.cpp 
6fdb85b3d55339556b0982598d2e5258f6159466 
  src/tests/containerizer/provisioner_docker_tests.cpp 
2efe64f7896beb97f14aa2754569bd8383a67ac7 

Diff: https://reviews.apache.org/r/39331/diff/


Testing
-------

make check (ubuntu14.04 + clang-3.6)

*This is not ready to be merged.
*Still considering two question:
 1. Handling simultaneous failure. If the first request is called and is 
written into the hashmap. All the other requests will be waiting for the future 
of the first request. But because its return type is 'Future<vector<string>>', 
if its future status is 'FAILED/DISCARDED', the other requests will be waiting 
forever. 
    Solved by logic check: if it is the first call to get() Image_A, promise 
associate with metadateManager->get(). If not, check whether that promised 
future failed/discarded. If yes, over write to the hashmap.
    
 2. The current hashmap uses 'stringify(image::name)' as key, but it may not be 
unique because there is chance that layer_ids can be changed. 
    One solution is to have 'stringify(image)' as key.


Thanks,

Gilbert Song

Reply via email to