I'm fine with prohibiting non-unique IDs, but why do you plan to keep the most recent in case of a conflict? I'd expect any duplicate (that we can find out) is rejected / killed / banned / unchurched.
On 9 Dec 2016 8:13 pm, "Joris Van Remoortere" <[email protected]> wrote: > Hey Neil, > > I concur that using duplicate task IDs is bad practice and asking for > trouble. > > Could you please clarify *why* you want to use a hashmap? Is your goal to > remove duplicate task IDs or is this just a side-effect and you have a > different reason (e.g. performance) for using a hashmap? > > I'm wondering why a multi-hashmap is not sufficient. This would be clear if > you were explicitly *trying* to get rid of duplicates of course :-) > > Thanks, > Joris > > — > *Joris Van Remoortere* > Mesosphere > > On Fri, Dec 9, 2016 at 7:08 AM, Neil Conway <[email protected]> wrote: > > > Folks, > > > > The master stores a cache of metadata about recently completed tasks; > > for example, this information can be accessed via the "/tasks" HTTP > > endpoint or the "GET_TASKS" call in the new Operator API. > > > > The master currently stores this metadata using a list; this means > > that duplicate task IDs are permitted. We're considering [1] changing > > this to use a hashmap instead. Using a hashmap would mean that > > duplicate task IDs would be discarded: if two completed tasks have the > > same task ID, only the metadata for the most recently completed task > > would be retained by the master. > > > > If this behavior change would cause problems for your framework or > > other software that relies on Mesos, please let me know. > > > > (Note that if you do have two completed tasks with the same ID, you'd > > need an unambiguous way to tell them apart. As a recommendation, I > > would strongly encourage framework authors to never reuse task IDs.) > > > > Neil > > > > [1] https://reviews.apache.org/r/54179/ > > >
