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 <[email protected]> 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? > >
