Vertx Instances & the JVM

[jeremy....@hulu.com]

I have a couple questions about how instances work mostly related to the JVM

• When I give the -instances option on the command line when running a vertical does it start each vertical in its own JVM or just as its own thread, i.e. '-instances 12' would be 12 JVMs or 12 threads with their own event loops? 
• How does 'static' variables/data work across verticals? Will one vertical see the same statically defined variables of another vertical? (if they are in the same JVM etc..)
  
• How does the classpath of each vertical work, can I have multiple versions of the same library being used by different verticals at the same time?
• Is it possible to tweak the settings of the JVM that is running the verticals?

[javajosh]

These are good questions, but which are all answerable with a few simple experiments (which should be treated as more canonical than any information you get on the mailing list, documentation, or even source code!) Below I've spelled out the experiment you can do to answer your own questions:

On Tuesday, August 6, 2013 7:14:11 AM UTC-7, jeremy....@hulu.com wrote:

I have a couple questions about how instances work mostly related to the JVM

• When I give the -instances option on the command line when running a vertical does it start each vertical in its own JVM or just as its own thread, i.e. '-instances 12' would be 12 JVMs or 12 threads with their own event loops?

With a sample module or verticle, run it with one and then multiple instances. Then check your native process count, perhaps with ps. How many do you see? If there is more than one then you have a JVM per verticle instance. [You won't see more than one.]

• How does 'static' variables/data work across verticals? Will one vertical see the same statically defined variables of another vertical? (if they are in the same JVM etc..)
  

Within a sample module, define two verticles. Deploy one instance of each. Define a class with a static, mutable member. Have both verticles print out the value of the static member then alter it's value. If the printout is the same, then there is classloader isolation between verticles. If they are different, then there isn't. 

• How does the classpath of each vertical work, can I have multiple versions of the same library being used by different verticals at the same time?

The result of the previous experiment will answer that question. 

• Is it possible to tweak the settings of the JVM that is running the verticals?

Okay, this one can't be answered by experiment, but only by either tracing the vertx invocation script or just knowing about the JVM. The short answer is "yes". The slightly longer answer is that you will need to set an environment variable called JVM_OPTS that will be passed to the 'java' process that vertx invokes.

As with most experiments, the hardest part of the problem is a) figuring out the experiment, and b) learning enough to actually carry it out! In this case, the "sample module" is the hard part, as the vertx-gradle-template or maven archetype (which I can't remember the name) is your best starting point. This begs the question: what is the simplest possible code you could write to do these experiments?

Here's my take:

ClassloaderTest.groovy:

class Foo{

  static String bar = "a static value"

  static boolean deployed = false

}

println "Classloader test loaded"

vertx.setPeriodic 500, {

  println "hello world: ${Foo.bar}"

}

int i = 0

vertx.setPeriodic 1000, {

  Foo.bar += "*"

  if (i++ > 5) container.exit()

}

if (!Foo.deployed){

  container.deployVerticle("ClassloaderTest.groovy")

  Foo.deployed = true

}

run with:

vertx run ClassloaderTest.groovy -instances 1

[javajosh]

So, not to give anything away, but that code has some "interesting" output. I'd love to have a method in vertx, something like "deployChildVerticle" that deploys a verticle with it's own classloader, but setting "this" verticle as it's parent - so that at least the child could read static state from the parent (which would be enough to make this example work, and I imagine would be enough for many cases).

[Jeremy Truelove]

Yeah I'm familiar with how to write the experiments but for those having worked with the framework these questions should be easy to answer and something the docs ultimately should reflect, I shouldn't need to write code to get a clear picture of how core parts of the framework work. 

--
You received this message because you are subscribed to a topic in the Google Groups "vert.x" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/vertx/3ZkKqko6y7o/unsubscribe.
To unsubscribe from this group and all of its topics, send an email to vertx+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[javajosh]

On Tuesday, August 6, 2013 8:22:19 AM UTC-7, Jeremy Truelove wrote:

Yeah I'm familiar with how to write the experiments but for those having worked with the framework these questions should be easy to answer and something the docs ultimately should reflect, I shouldn't need to write code to get a clear picture of how core parts of the framework work. 

gosh, you're welcome!

[Jeremy Truelove]

Thanks!

[Tim Fox]

I believe all of this is answered in the documentation, but here are
some pointers

On 06/08/13 15:14, jeremy....@hulu.com wrote:
> I have a couple questions about how instances work mostly related to the JVM
>
>

> - When I give the -instances option on the command line when running a

> vertical does it start each vertical in its own JVM or just as its own
> thread, i.e. '-instances 12' would be 12 JVMs or 12 threads with their own
> event loops?

Neither. It starts each instance in a single JVM. A fixed number of
threads (equal to number of cores) is distributed amongst the instances.
See the main manual for more info.

> - How does 'static' variables/data work across verticals? Will one

> vertical see the same statically defined variables of another vertical? (if
> they are in the same JVM etc..)

See "module classloaders" in the modules manual.

> - How does the classpath of each vertical work, can I have multiple

> versions of the same library being used by different verticals at the same
> time?

Yes, again see module classloaders.
> - Is it possible to tweak the settings of the JVM that is running the
> verticals?
>
Yes, you can edit the vertx script

[javajosh]

On Tuesday, August 6, 2013 9:48:39 AM UTC-7, Tim Fox wrote:

On 06/08/13 15:14, jeremy....@hulu.com wrote:
> I have a couple questions about how instances work mostly related to the JVM
>
>
>     - When I give the -instances option on the command line when running a
>     vertical does it start each vertical in its own JVM or just as its own
>     thread, i.e. '-instances 12' would be 12 JVMs or 12 threads with their own
>     event loops?

Neither. It starts each instance in a single JVM. A fixed number of
threads (equal to number of cores) is distributed amongst the instances.
See the main manual for more info.

This is ambiguous explaination, because there is confusion between what "instance" means. There is a vertx instance, and there is a verticle instance. There is one vertx instane per JVM, but there are multiple verticle instances per vertx instance. This could be misread to imply that -instances launches multiple vertx instances, which is not true.

[Tim Fox]

On 06/08/13 18:13, javajosh wrote:
>
> On Tuesday, August 6, 2013 9:48:39 AM UTC-7, Tim Fox wrote:
>>

>> On 06/08/13 15:14, jeremy....@hulu.com <javascript:> wrote:
>>> I have a couple questions about how instances work mostly related to the
>> JVM
>>>
>>> - When I give the -instances option on the command line when running
>> a
>>> vertical does it start each vertical in its own JVM or just as its
>> own
>>> thread, i.e. '-instances 12' would be 12 JVMs or 12 threads with
>> their own
>>> event loops?
>> Neither. It starts each instance in a single JVM. A fixed number of
>> threads (equal to number of cores) is distributed amongst the instances.
>> See the main manual for more info.
>>
> This is ambiguous explaination, because there is confusion between what
> "instance" means. There is a vertx instance, and there is a verticle
> instance. There is one vertx instane per JVM, but there are multiple
> verticle instances per vertx instance. This could be misread to imply that
> -instances launches multiple vertx instances, which is not true.

Right. The -instances means "instances of the verticle", not "instances
of vertx"
>

[Jeremy Truelove]

Thanks this was helpful, I was missing the module class loader piece. So
in the case of running the raw vertical with the 'instances' parameter is
it correct to say each vertical uses the same class loader for each
instance and they therefore share any static data? Just like when you load
multiple instances of the same version of a module? One other question so
vertx always tries to saturate all the CPUs on a box if I'm understanding
things.

[Tim Fox]

On 06/08/13 18:17, Jeremy Truelove wrote:
> Thanks this was helpful, I was missing the module class loader piece. So
> in the case of running the raw vertical with the 'instances' parameter is
> it correct to say each vertical uses the same class loader for each
> instance and they therefore share any static data?

That's correct.

> Just like when you load
> multiple instances of the same version of a module?

Exactly.

> One other question so
> vertx always tries to saturate all the CPUs on a box if I'm understanding
> things.

Yes.

[Jeremy Truelove]

So does this then imply that if I'm only running one type of thing (or
module) I don't need to create multiple instances of it in vertx, as vertx
will handle trying to scale it out across all the processors regardless?

[Angelo K H]

I don't think your statement is true. Static data is not shared. Here is my setup.

public class SimpleServer extends Verticle {
 public static Integer simpleInt = 3;
 public void start() {
 container.deployVerticle("simple/EchoServer.java");
 container.deployVerticle("simple/HelloWorldServer.java");
 }
}

public class Common {
 public static Integer myInt = 3;
}

public class EchoServer extends Verticle {
  public void start() {
  System.out.println(">>> Starting Echo Server");
  System.out.println(">>> Echo: Int is " + Common.myInt);
    vertx.createNetServer().connectHandler(new Handler<NetSocket>() {
      public void handle(final NetSocket socket) {
        Pump.createPump(socket, socket).start();
      }
    }).listen(1234);
    Common.myInt += 100;
    System.out.println(">>> Echo: new Int is " + Common.myInt);
  }
}

public class HelloWorldServer extends Verticle {
  public void start() {
  System.out.println(">>> Starting HelloWorld Server");
  System.out.println(">>> HelloWorld: Int is " + Common.myInt);
    vertx.createHttpServer().requestHandler(new Handler<HttpServerRequest>() {
      public void handle(HttpServerRequest req) {
        req.response().headers().set("Content-Type", "text/plain");
        req.response().end("Hello World");
      }
    }).listen(8080);
    try {
    Thread.sleep(1000);
    } catch (InterruptedException ie) {
   
    }
    System.out.println(">>> HelloWorld: new Int is " + Common.myInt);
  }
}

The result is:

$ vertx runmod io.vertx~simple-source-mod~1.0
>>> Starting Echo Server
>>> Echo: Int is 3
>>> Starting HelloWorld Server
>>> HelloWorld: Int is 3
>>> Echo: new Int is 103
>>> HelloWorld: new Int is 3

The static data is not shared between verticles. It is owned by different class loader.