Yes, all good questions. These questions are a part of the design for our system, which runs user provided Java code written specifically to our API. While it is possible we may separate it out in the future as our system evolves, the current needs are met with running user code in the same JVM. Thanks, that does help. Sharma
On Tue, Mar 11, 2014 at 11:56 AM, Benjamin Mahler <benjamin.mah...@gmail.com > wrote: > If you're just loading a .jar then I suppose you are ok, but I'm not sure > if this is a wise design for running arbitrary .jars. You'll be able to > share the JVM overhead but you'll also be sharing the same JVM runtime, is > that well supported? > > What happens if both your executor .jar and the task .jar have conflicting > library dependencies? What happens if the task .jar crashes the JVM? I'm > not a Java expert so it would be good to discuss this with someone else who > better understands the implications of this shared JVM design. > > Hope that helps, > Ben > > > On Mon, Mar 10, 2014 at 10:03 PM, Sharma Podila <spod...@netflix.com>wrote: > >> Thank you for the confirmation and the pointer to the 1 sec sleep. >> Yes, I meant TASK_FINISHED. >> >> >>> If you don't want to implement an Executor and your Task merely consists >>> of forking an arbitrary process, you can use the built-in "Command >>> Executor". You can launch a task directly in this manner by specifying a >>> CommandInfo inside your TaskInfo (see the documentation in mesos.proto). >>> Unless you're using the "Command Executor", you will still need to >>> implement "forking and process management". >>> >>> >> I do have an Executor implementation in Java to handle all the callbacks >> from the driver. The launchTask implementation simply loads the task's jar >> and runs the code in the same JVM. In this case, it sounds like I don't >> need to implement forking and process management. Unless there's something >> else I am missing? >> >> >
