You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@reef.apache.org by Andrew Chung <af...@gmail.com> on 2016/01/28 00:47:23 UTC
Ability to support multiple Tasks on an Evaluator
Hi all,
The request to support multiple Tasks on a single Evaluator has been coming
up quite a bit internally within Microsoft. Is this a feature that everyone
would like to use? Should this be in core REEF? Or should this be built as
an application on top of REEF? If we were to merge this into core REEF,
some of the existing Task API may break or will need to be deprecated
first. Finally, given that users within Microsoft are mostly using REEF.NET,
this feature will be implemented in REEF.NET first. Would there be interest
for someone to pick this up on the Java side?
What does everyone think?
Thanks,
Andrew
Re: Ability to support multiple Tasks on an Evaluator
Posted by Markus Weimer <ma...@weimo.de>.
> Our first question to answer, however, is whether or not this is a
> service that people would like to have in the open source codebase.
> What do you think?
Definite +1 from me. We can work out how to minimally break things as we
design and build this.
Markus
Re: Ability to support multiple Tasks on an Evaluator
Posted by Markus Weimer <ma...@weimo.de>.
On 2016-02-11 23:51, Andrew Chung wrote:
>Sorry for the overloading of terms, I don't have
> a good name for these sub-tasks. Any suggestions for the name?
Maybe TaskLets for the tasks run in the multi-task scenario? Or MTask,
as in `MultiTaskTask`?
Markus
Re: Ability to support multiple Tasks on an Evaluator
Posted by John Yang <jo...@gmail.com>.
Thanks Andrew for the explanation, the plan sounds good.
Yes, using the same names can be a bit confusing, however I'm afraid I
don't have any good ideas either.
Thanks,
John
On Fri, Feb 12, 2016 at 4:51 PM, Andrew Chung <af...@gmail.com> wrote:
> Thanks for the feedback John!
> Yes, I believe Vortex can certainly benefit from the service, although
> it will likely be implemented in C# first.
> I was thinking about simply using Task#sendMessage, since the host
> Task will be the one to spin off additional Tasks on the Evaluator,
> just like in Vortex. Sorry for the overloading of terms, I don't have
> a good name for these sub-tasks. Any suggestions for the name?
>
> Thanks,
> Andrew
>
> On Wed, Feb 10, 2016 at 10:47 PM, John Yang <jo...@gmail.com> wrote:
> > Hi,
> >
> >
> > Implementing the Multi-Task API using a service sounds great. We can
> even
> > re-write Vortex to use the API, doing without the boilerplate code.
> >
> > I think the following parameters used in Vortex can also be included in
> the
> > Multi-Task configuration.
> >
> > - Maximum number of tasks that can concurrently run at a time within
> an
> > Evaluator
> > - Maximum number of tasks that can wait to be executed (equal or
> bigger
> > than the first parameter) within an Evaluator
> >
> > Also, it'd be great if the user can send custom messages from the Driver
> to
> > an Evaluator. I guess this can be done using an existing channel
> > like ActiveContext#sendMessage?
> >
> >
> > Thanks,
> > John
> >
> >
> > On Fri, Jan 29, 2016 at 7:46 AM, Byung-Gon Chun <bg...@gmail.com>
> wrote:
> >
> >> On Fri, Jan 29, 2016 at 3:17 AM, Andrew Chung <af...@gmail.com>
> wrote:
> >>
> >> > Hi,
> >> >
> >> > Thanks for the comments Markus!
> >> >
> >> > A way I am thinking to implement this now is as follows:
> >> > User calls SubmitTask with a Multi-Task TaskConfiguration. The
> >> > Multi-Task Task starts a service on top of the Evaluator, and accepts
> >> > incoming tasks and injects REEF Tasks based on the TaskConfiguration
> >> > that the user passes to the service: this way, the user doesn't need
> >> > to rewrite their Tasks to fit into a new Multi-Task object. In order
> >> > for tasks to use contexts, we will need to expose a hook from Core
> >> > REEF such that the ContextConfiguration of a REEF Context is bound to
> >> > the user's Multi-Task TaskConfiguration.
> >> >
> >>
> >> With Multi-Task, can you run "Tasks" (it may be good to introduce a new
> >> term, REEF Task is confusing to me) concurrently?
> >> (We may be able to re-use some of the Vortex codebase.)
> >>
> >> Can you share specific use cases of Multi-Task you have in mind?
> >>
> >>
> >>
> >> > I'm sure there are some other issues that I am overlooking right now,
> >> > but they will appear as we begin implementing the service. Our first
> >> > question to answer, however, is whether or not this is a service that
> >> > people would like to have in the open source codebase. What do you
> >> > think?
> >> >
> >>
> >> Yes, of course.
> >>
> >> Thanks!
> >>
> >>
> >> >
> >> > Thanks,
> >> > Andrew
> >> >
> >> > On Wed, Jan 27, 2016 at 4:38 PM, Markus Weimer <ma...@weimo.de>
> wrote:
> >> > > On 2016-01-27 15:47, Andrew Chung wrote:
> >> > >>
> >> > >> The request to support multiple Tasks on a single Evaluator has
> been
> >> > >> coming up quite a bit internally within Microsoft. Is this a
> feature
> >> > >> that everyone would like to use? Should this be in core REEF? Or
> >> > >> should this be built as an application on top of REEF?
> >> > >
> >> > >
> >> > > +1 on treating it as a service like naming service or the group
> >> > > communications service. If possible, we should avoid breakage of
> core
> >> > APIs.
> >> > >
> >> > > That said, if we don't have the needed hooks for a layer like this,
> >> then
> >> > we
> >> > > should by all means add more hooks into core REEF.
> >> > >
> >> > > One question I have is whether or not today's applications need to
> be
> >> > able
> >> > > to execute on this new multi-task layer. If not, this new
> functionality
> >> > can
> >> > > be implemented by a single `Task` on the Evaluator side and
> presented
> >> as
> >> > a
> >> > > bunch of new APIs / Events / Event Handlers on the Driver side.
> >> > >
> >> > > Or am I missing something?
> >> > >
> >> > > Markus
> >> >
> >>
> >>
> >>
> >> --
> >> Byung-Gon Chun
> >>
>
Re: Ability to support multiple Tasks on an Evaluator
Posted by Andrew Chung <af...@gmail.com>.
Thanks for the feedback John!
Yes, I believe Vortex can certainly benefit from the service, although
it will likely be implemented in C# first.
I was thinking about simply using Task#sendMessage, since the host
Task will be the one to spin off additional Tasks on the Evaluator,
just like in Vortex. Sorry for the overloading of terms, I don't have
a good name for these sub-tasks. Any suggestions for the name?
Thanks,
Andrew
On Wed, Feb 10, 2016 at 10:47 PM, John Yang <jo...@gmail.com> wrote:
> Hi,
>
>
> Implementing the Multi-Task API using a service sounds great. We can even
> re-write Vortex to use the API, doing without the boilerplate code.
>
> I think the following parameters used in Vortex can also be included in the
> Multi-Task configuration.
>
> - Maximum number of tasks that can concurrently run at a time within an
> Evaluator
> - Maximum number of tasks that can wait to be executed (equal or bigger
> than the first parameter) within an Evaluator
>
> Also, it'd be great if the user can send custom messages from the Driver to
> an Evaluator. I guess this can be done using an existing channel
> like ActiveContext#sendMessage?
>
>
> Thanks,
> John
>
>
> On Fri, Jan 29, 2016 at 7:46 AM, Byung-Gon Chun <bg...@gmail.com> wrote:
>
>> On Fri, Jan 29, 2016 at 3:17 AM, Andrew Chung <af...@gmail.com> wrote:
>>
>> > Hi,
>> >
>> > Thanks for the comments Markus!
>> >
>> > A way I am thinking to implement this now is as follows:
>> > User calls SubmitTask with a Multi-Task TaskConfiguration. The
>> > Multi-Task Task starts a service on top of the Evaluator, and accepts
>> > incoming tasks and injects REEF Tasks based on the TaskConfiguration
>> > that the user passes to the service: this way, the user doesn't need
>> > to rewrite their Tasks to fit into a new Multi-Task object. In order
>> > for tasks to use contexts, we will need to expose a hook from Core
>> > REEF such that the ContextConfiguration of a REEF Context is bound to
>> > the user's Multi-Task TaskConfiguration.
>> >
>>
>> With Multi-Task, can you run "Tasks" (it may be good to introduce a new
>> term, REEF Task is confusing to me) concurrently?
>> (We may be able to re-use some of the Vortex codebase.)
>>
>> Can you share specific use cases of Multi-Task you have in mind?
>>
>>
>>
>> > I'm sure there are some other issues that I am overlooking right now,
>> > but they will appear as we begin implementing the service. Our first
>> > question to answer, however, is whether or not this is a service that
>> > people would like to have in the open source codebase. What do you
>> > think?
>> >
>>
>> Yes, of course.
>>
>> Thanks!
>>
>>
>> >
>> > Thanks,
>> > Andrew
>> >
>> > On Wed, Jan 27, 2016 at 4:38 PM, Markus Weimer <ma...@weimo.de> wrote:
>> > > On 2016-01-27 15:47, Andrew Chung wrote:
>> > >>
>> > >> The request to support multiple Tasks on a single Evaluator has been
>> > >> coming up quite a bit internally within Microsoft. Is this a feature
>> > >> that everyone would like to use? Should this be in core REEF? Or
>> > >> should this be built as an application on top of REEF?
>> > >
>> > >
>> > > +1 on treating it as a service like naming service or the group
>> > > communications service. If possible, we should avoid breakage of core
>> > APIs.
>> > >
>> > > That said, if we don't have the needed hooks for a layer like this,
>> then
>> > we
>> > > should by all means add more hooks into core REEF.
>> > >
>> > > One question I have is whether or not today's applications need to be
>> > able
>> > > to execute on this new multi-task layer. If not, this new functionality
>> > can
>> > > be implemented by a single `Task` on the Evaluator side and presented
>> as
>> > a
>> > > bunch of new APIs / Events / Event Handlers on the Driver side.
>> > >
>> > > Or am I missing something?
>> > >
>> > > Markus
>> >
>>
>>
>>
>> --
>> Byung-Gon Chun
>>
Re: Ability to support multiple Tasks on an Evaluator
Posted by John Yang <jo...@gmail.com>.
Hi,
Implementing the Multi-Task API using a service sounds great. We can even
re-write Vortex to use the API, doing without the boilerplate code.
I think the following parameters used in Vortex can also be included in the
Multi-Task configuration.
- Maximum number of tasks that can concurrently run at a time within an
Evaluator
- Maximum number of tasks that can wait to be executed (equal or bigger
than the first parameter) within an Evaluator
Also, it'd be great if the user can send custom messages from the Driver to
an Evaluator. I guess this can be done using an existing channel
like ActiveContext#sendMessage?
Thanks,
John
On Fri, Jan 29, 2016 at 7:46 AM, Byung-Gon Chun <bg...@gmail.com> wrote:
> On Fri, Jan 29, 2016 at 3:17 AM, Andrew Chung <af...@gmail.com> wrote:
>
> > Hi,
> >
> > Thanks for the comments Markus!
> >
> > A way I am thinking to implement this now is as follows:
> > User calls SubmitTask with a Multi-Task TaskConfiguration. The
> > Multi-Task Task starts a service on top of the Evaluator, and accepts
> > incoming tasks and injects REEF Tasks based on the TaskConfiguration
> > that the user passes to the service: this way, the user doesn't need
> > to rewrite their Tasks to fit into a new Multi-Task object. In order
> > for tasks to use contexts, we will need to expose a hook from Core
> > REEF such that the ContextConfiguration of a REEF Context is bound to
> > the user's Multi-Task TaskConfiguration.
> >
>
> With Multi-Task, can you run "Tasks" (it may be good to introduce a new
> term, REEF Task is confusing to me) concurrently?
> (We may be able to re-use some of the Vortex codebase.)
>
> Can you share specific use cases of Multi-Task you have in mind?
>
>
>
> > I'm sure there are some other issues that I am overlooking right now,
> > but they will appear as we begin implementing the service. Our first
> > question to answer, however, is whether or not this is a service that
> > people would like to have in the open source codebase. What do you
> > think?
> >
>
> Yes, of course.
>
> Thanks!
>
>
> >
> > Thanks,
> > Andrew
> >
> > On Wed, Jan 27, 2016 at 4:38 PM, Markus Weimer <ma...@weimo.de> wrote:
> > > On 2016-01-27 15:47, Andrew Chung wrote:
> > >>
> > >> The request to support multiple Tasks on a single Evaluator has been
> > >> coming up quite a bit internally within Microsoft. Is this a feature
> > >> that everyone would like to use? Should this be in core REEF? Or
> > >> should this be built as an application on top of REEF?
> > >
> > >
> > > +1 on treating it as a service like naming service or the group
> > > communications service. If possible, we should avoid breakage of core
> > APIs.
> > >
> > > That said, if we don't have the needed hooks for a layer like this,
> then
> > we
> > > should by all means add more hooks into core REEF.
> > >
> > > One question I have is whether or not today's applications need to be
> > able
> > > to execute on this new multi-task layer. If not, this new functionality
> > can
> > > be implemented by a single `Task` on the Evaluator side and presented
> as
> > a
> > > bunch of new APIs / Events / Event Handlers on the Driver side.
> > >
> > > Or am I missing something?
> > >
> > > Markus
> >
>
>
>
> --
> Byung-Gon Chun
>
Re: Ability to support multiple Tasks on an Evaluator
Posted by Byung-Gon Chun <bg...@gmail.com>.
On Fri, Jan 29, 2016 at 3:17 AM, Andrew Chung <af...@gmail.com> wrote:
> Hi,
>
> Thanks for the comments Markus!
>
> A way I am thinking to implement this now is as follows:
> User calls SubmitTask with a Multi-Task TaskConfiguration. The
> Multi-Task Task starts a service on top of the Evaluator, and accepts
> incoming tasks and injects REEF Tasks based on the TaskConfiguration
> that the user passes to the service: this way, the user doesn't need
> to rewrite their Tasks to fit into a new Multi-Task object. In order
> for tasks to use contexts, we will need to expose a hook from Core
> REEF such that the ContextConfiguration of a REEF Context is bound to
> the user's Multi-Task TaskConfiguration.
>
With Multi-Task, can you run "Tasks" (it may be good to introduce a new
term, REEF Task is confusing to me) concurrently?
(We may be able to re-use some of the Vortex codebase.)
Can you share specific use cases of Multi-Task you have in mind?
> I'm sure there are some other issues that I am overlooking right now,
> but they will appear as we begin implementing the service. Our first
> question to answer, however, is whether or not this is a service that
> people would like to have in the open source codebase. What do you
> think?
>
Yes, of course.
Thanks!
>
> Thanks,
> Andrew
>
> On Wed, Jan 27, 2016 at 4:38 PM, Markus Weimer <ma...@weimo.de> wrote:
> > On 2016-01-27 15:47, Andrew Chung wrote:
> >>
> >> The request to support multiple Tasks on a single Evaluator has been
> >> coming up quite a bit internally within Microsoft. Is this a feature
> >> that everyone would like to use? Should this be in core REEF? Or
> >> should this be built as an application on top of REEF?
> >
> >
> > +1 on treating it as a service like naming service or the group
> > communications service. If possible, we should avoid breakage of core
> APIs.
> >
> > That said, if we don't have the needed hooks for a layer like this, then
> we
> > should by all means add more hooks into core REEF.
> >
> > One question I have is whether or not today's applications need to be
> able
> > to execute on this new multi-task layer. If not, this new functionality
> can
> > be implemented by a single `Task` on the Evaluator side and presented as
> a
> > bunch of new APIs / Events / Event Handlers on the Driver side.
> >
> > Or am I missing something?
> >
> > Markus
>
--
Byung-Gon Chun
Re: Ability to support multiple Tasks on an Evaluator
Posted by Andrew Chung <af...@gmail.com>.
Hi,
Thanks for the comments Markus!
A way I am thinking to implement this now is as follows:
User calls SubmitTask with a Multi-Task TaskConfiguration. The
Multi-Task Task starts a service on top of the Evaluator, and accepts
incoming tasks and injects REEF Tasks based on the TaskConfiguration
that the user passes to the service: this way, the user doesn't need
to rewrite their Tasks to fit into a new Multi-Task object. In order
for tasks to use contexts, we will need to expose a hook from Core
REEF such that the ContextConfiguration of a REEF Context is bound to
the user's Multi-Task TaskConfiguration.
I'm sure there are some other issues that I am overlooking right now,
but they will appear as we begin implementing the service. Our first
question to answer, however, is whether or not this is a service that
people would like to have in the open source codebase. What do you
think?
Thanks,
Andrew
On Wed, Jan 27, 2016 at 4:38 PM, Markus Weimer <ma...@weimo.de> wrote:
> On 2016-01-27 15:47, Andrew Chung wrote:
>>
>> The request to support multiple Tasks on a single Evaluator has been
>> coming up quite a bit internally within Microsoft. Is this a feature
>> that everyone would like to use? Should this be in core REEF? Or
>> should this be built as an application on top of REEF?
>
>
> +1 on treating it as a service like naming service or the group
> communications service. If possible, we should avoid breakage of core APIs.
>
> That said, if we don't have the needed hooks for a layer like this, then we
> should by all means add more hooks into core REEF.
>
> One question I have is whether or not today's applications need to be able
> to execute on this new multi-task layer. If not, this new functionality can
> be implemented by a single `Task` on the Evaluator side and presented as a
> bunch of new APIs / Events / Event Handlers on the Driver side.
>
> Or am I missing something?
>
> Markus
Re: Ability to support multiple Tasks on an Evaluator
Posted by Markus Weimer <ma...@weimo.de>.
On 2016-01-27 15:47, Andrew Chung wrote:
> The request to support multiple Tasks on a single Evaluator has been
> coming up quite a bit internally within Microsoft. Is this a feature
> that everyone would like to use? Should this be in core REEF? Or
> should this be built as an application on top of REEF?
+1 on treating it as a service like naming service or the group
communications service. If possible, we should avoid breakage of core APIs.
That said, if we don't have the needed hooks for a layer like this, then
we should by all means add more hooks into core REEF.
One question I have is whether or not today's applications need to be
able to execute on this new multi-task layer. If not, this new
functionality can be implemented by a single `Task` on the Evaluator
side and presented as a bunch of new APIs / Events / Event Handlers on
the Driver side.
Or am I missing something?
Markus
Re: Ability to support multiple Tasks on an Evaluator
Posted by Andrew Chung <af...@gmail.com>.
Hi Gon,
It depends on how we want to implement it. A way is to merge it into
core REEF, which is expected to be a lot more difficult due to the
need to break APIs. Another way is to build an application on top of
it as was done in Vortex; however, this will likely be more general
than Vortex since users will need to be able to specify their
resources and all the other features that REEF provides. Which way do
you think is better? We can certainly have it sit on top of the
current Task API, but a problem will be the ability to inject objects
that are bound in `ContextConfiguration`. Another problem is that this
becomes another application that is potentially independent of the
rest of the applications that we will have to support going forward.
So far, I have not yet thought of a good way to expose both the core
REEF Task AND core REEF Context AND the application Task all at once.
What do you think?
Thanks,
Andrew
On Wed, Jan 27, 2016 at 4:01 PM, Byung-Gon Chun <bg...@gmail.com> wrote:
> Thanks, Andrew!
>
> Is this new API quite different from the Vortex Tasklet API?
> Should the API be natively supported by REEF? Or can it sit on the current
> Task API? The current Task API served what it's intended pretty well.
>
> Thanks.
> -Gon
>
>
> On Thu, Jan 28, 2016 at 8:47 AM, Andrew Chung <af...@gmail.com> wrote:
>
>> Hi all,
>>
>> The request to support multiple Tasks on a single Evaluator has been coming
>> up quite a bit internally within Microsoft. Is this a feature that everyone
>> would like to use? Should this be in core REEF? Or should this be built as
>> an application on top of REEF? If we were to merge this into core REEF,
>> some of the existing Task API may break or will need to be deprecated
>> first. Finally, given that users within Microsoft are mostly using
>> REEF.NET,
>> this feature will be implemented in REEF.NET first. Would there be
>> interest
>> for someone to pick this up on the Java side?
>>
>> What does everyone think?
>>
>> Thanks,
>> Andrew
>>
>
>
>
> --
> Byung-Gon Chun
Re: Ability to support multiple Tasks on an Evaluator
Posted by Byung-Gon Chun <bg...@gmail.com>.
Thanks, Andrew!
Is this new API quite different from the Vortex Tasklet API?
Should the API be natively supported by REEF? Or can it sit on the current
Task API? The current Task API served what it's intended pretty well.
Thanks.
-Gon
On Thu, Jan 28, 2016 at 8:47 AM, Andrew Chung <af...@gmail.com> wrote:
> Hi all,
>
> The request to support multiple Tasks on a single Evaluator has been coming
> up quite a bit internally within Microsoft. Is this a feature that everyone
> would like to use? Should this be in core REEF? Or should this be built as
> an application on top of REEF? If we were to merge this into core REEF,
> some of the existing Task API may break or will need to be deprecated
> first. Finally, given that users within Microsoft are mostly using
> REEF.NET,
> this feature will be implemented in REEF.NET first. Would there be
> interest
> for someone to pick this up on the Java side?
>
> What does everyone think?
>
> Thanks,
> Andrew
>
--
Byung-Gon Chun