Hi Robert, I also think parallelization of fetching is important for many use cases to reduce the time it takes to launch a task. Can we make sure the it's still possible to parallel downloads if you file a feature request?
Also, when a task is launched, all URIs should be already fetched into sandbox, so I'm very interested how out-of-order could break your use case. On Mon, Jun 20, 2016 at 12:36 PM, Jie Yu <[email protected]> wrote: > Robert, I just checked the code and the ordering is not guaranteed since > we parallelize the download currently. > > This sounds like a feature request. Robert, do you want to create a > ticket? For now, i think a startup script should be able to workaround that. > > On Mon, Jun 20, 2016 at 11:02 AM, Robert Lacroix <[email protected]> > wrote: > >> Jie, would it hurt if we would guarantee ordering of URIs? I could see >> use cases where the order in which files are extracted matters. Protobuf >> preserves ordering of repeated fields, so it shouldn't be a huge effort (it >> probably already works). >> >> Robert >> >> On Jun 17, 2016, at 7:37 PM, Jie Yu <[email protected]> wrote: >> >> There is no ordering assumption in the API. >> >> - Jie >> >> On Fri, Jun 17, 2016 at 10:33 AM, Wil Yegelwel <[email protected]> >> wrote: >> >>> I'm curious whether there is an ordering assumption on the CommandInfo >>> protobuf or if the order does not matter. The comment in mesos.proto, "Any >>> URIs specified are fetched before executing the command" seems to imply >>> that ordering does not matter. I just wanted to confirm that was the case. >>> >>> Thanks, >>> Wil >>> >> >> >> > -- Cheers, Zhitao Li
