Yes, it'll be a bit more complex. The reason I mention it is because all
callbacks in the scheduler interface are single threaded so on a large/busy
cluster this could stall things. You want to do as little as possible in
any of the callbacks. It would be great to write a benchmark for
resourceOffers()

On Friday, April 25, 2014, Dario Rexin <notifications@github.com> wrote:

> In src/main/scala/mesosphere/marathon/MarathonScheduler.scala:
>
> > @@ -73,12 +73,16 @@ class MarathonScheduler @Inject()(
> >        try {
> >          log.fine("Received offer %s".format(offer))
> >
> > -        // TODO launch multiple tasks if the offer is big enough
> > -        val app = taskQueue.poll()
> > +        val apps = taskQueue.removeAll()
>
> I'm not sure about this. I think it would make it more complex, because we
> would need to track what to add back to the queue and what not this way.
> Also when we keep it like this we can consider tasks that arrive while this
> code is running.
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/mesosphere/marathon/pull/231/files#r11989796>
> .
>