Classloader isolation in Vert.x 3.0

[Tim Fox]

The proposal to remove the module system and consequently the
classloader isolation in Vert.x 3.0 seems to have split people.. Some of
you would love to see it go in order to simplify things and others
really like the feature...

So, how about a compromise...

Let's say you do

vertx.deployVerticle(verticleClass)

By default this will simply run the verticle using the current
classloader - i.e. we have a single flat classpath in the application.

But if you want your verticle to be deployed isolated, then you can do
something like:

vertx.deployVerticle(verticleClass, isolated = true);

Then it will create a new classloader and instantiate the verticle using
that, and any other libraries loaded by that verticle will also be
loaded by that new classloader. So basically that verticle and anything
else it instantiates will live in its own new flat classpath.

That way we can remove the module system but still retain classloader
isolation, if required.

How does that sound?

[Nick Scavelli]

So where is vertx going to load classes from when it creates this new class loader ? If you're going this route maybe just have it accept a classloader ?

vertx.deployVerticle(String, ClassLoader);

This would allow people to do a lot of things. You could even download the verticle :)

[Tim Fox]

On 24/04/14 09:56, Nick Scavelli wrote:

So where is vertx going to load classes from when it creates this new class loader ?

I guess from the same set of URLs as the parent classloader.

If you're going this route maybe just have it accept a classloader ?

vertx.deployVerticle(String, ClassLoader);

I don't want to give people too much rope to hang themselves with ;) Trust me, if we allow this people will use hideously broken custom classes then expect me to debug their application when it doesn't work. No thanks.

This would allow people to do a lot of things. You could even download the verticle :)

On Thursday, April 24, 2014 8:45:16 AM UTC-4, Tim Fox wrote:

The proposal to remove the module system and consequently the
classloader isolation in Vert.x 3.0 seems to have split people.. Some of
you would love to see it go in order to simplify things and others
really like the feature...

So, how about a compromise...

Let's say you do

vertx.deployVerticle(verticleClass)

By default this will simply run the verticle using the current
classloader - i.e. we have a single flat classpath in the application.

But if you want your verticle to be deployed isolated, then you can do
something like:

vertx.deployVerticle(verticleClass, isolated = true);

Then it will create a new classloader and instantiate the verticle using
that, and any other libraries loaded by that verticle will also be
loaded by that new classloader. So basically that verticle and anything
else it instantiates will live in its own new flat classpath.

That way we can remove the module system but still retain classloader
isolation, if required.

How does that sound?

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Dean Pehrsson-Chapman]

How does that sound?

Definitely an improvement, although we have resource pools that are shared by multiple verticles which wouldn't fit with this (we'd end up with pool per verticle).

Could there be a way of providing all the 'platform' goodies (classloader separation and deployment, essentially?) that currently exist in a separate project, or some other mechanism that prevents people hanging themselves too easily? 

[Matthias Ohlemeyer]

Are these assumptions correct? If the module system goes away, with it goes mod.json, the ability to include the resources of other modules, the module registry, automatic installation of modules...

I thought that one of the strengths of the module system, is the ability to provide functionality for others to use, irrespective of the programming language it is written in.

Now, what happens in a world without Vert.x modules? Will a JavaScript developer have to use gem to install a Ruby verticle? (Will this be possible at all?) Will a java developer have to learn npm if he is interested in functionality provided today by a JavaScript module? Will reuse on the level of todays modules still be easy? Or will we have a Vert.x Java community, a Vert.x JavaScript community...

Please explain.

[Jordan Halterman]

What Matthias is asking is basically my concern as well. He just put it more elegantly that I could :-)

--

[Dean Pehrsson-Chapman]

How about:

vertx.deployVerticle(verticleClass, ClassloaderIsolation.FLAT) ;

vertx.deployVerticle(verticleClass, ClassloaderIsolation.ISOLATED); 

vertx.deployVerticle(verticleClass, ClassloaderIsolation.ISOLATED_INCLUDE_CURRENT); 

vertx.deployVerticle(verticleClass); //default - ClassloaderIsolation.FLAT 

I think that would give all the functionality we currently have (but people would need to be explicit about it), and stops people using their own wonky classloaders and expecting you to support.

[petermd]

Rather then trying to enum the permutations, how about just creating a VerticleGroup concept that incorporates a shared ClassLoader eg

vertx.deployVerticle(class)

vertx.deployVerticle(class,group)

this way you don't allow custom classloaders, but the deploying master verticle can define isolation groups that match their requirements. it could also be used to assign other resources (eg each group could have its own workerverticle threadpool) that might also need to be configured independently for third-party verticles.

nb still wondering if the problems people have with classloaders are because they are trying to share / compare instances inside the VM. since that's bad practice, won't work in a cluster etc, perhaps the default should be still be isolated classloader (per verticle class) with the option to share the classloader available only for those who need it?

-Peter

[Nick Scavelli]

+1, my concern as well. I really wonder how this looks and I fear it will split the community rather then bring it together.

[Sougata Bhattacharya]

This seems to be a nice idea.

[Arno Schulz]

This is an issue that can't be looked on by itself. Vert.X is a system and has to be taken as a whole.

1. If I understand Tim's vision correctly the following stands

Vert.X 2.x is Linux Containers

Vert.X 3.0 is Docker

Both are fundamentally the same but radically different at the same time

2. For the package management concerns, don't look at the classloader but rather at how you get the packages in the first place.

Going back docker has done something anyone in their sane minds it made linux package managers irrelevant and the dependency hell that they brought disappeared overnight.

Just go to https://index.docker.io/ pull the app you want and voila

A similar community maintained package curation proxy system could replace today's Vert.X module index (curation instead of source, it would include npm, gems, jars, etc... that work in Vert.X)

--

[Norman Maurer]

 Same here…

Maybe I misunderstand the whole proposal…

-- 
Norman Maurer

[Arno Schulz]

Typo "Going back docker has done something anyone in their sane minds" should read

Going back to docker has done something anyone in their sane minds would have thought was impossible it made linux package managers irrelevant and the dependency hell that they brought disappeared overnight.

I have first hand experience with docker, and I never thought about running an app designed for ubuntu (juju), along side a busybox image (ambassador for the db on another host) running on top of RHEL 6.5.

[Brice Dutheil]

I’m not opinionated on either vert.x should have two or more modes but I especially would highlight api retrocompatibility. It is really important to keep that in mind. retro-compatibility (API and behavioral wise) is not overrated !

Also I would not favor API proliferation, with additional method overloads, etc. What if there was other parameters to pass in vert.x 4, 5, 6, etc.

In mockito for example we have normal verification and we created a special verifier implementation for ordered verification, on which you can call the exact same methods, in other places we also have strategies (VerificationMode, Answer), or spec object (MockSettings). Rx uses the same style of API to create an Observable. So let’s promote this kind of API. For example iterating over the API that Dean Pehrsson-Chapman proposed :

vertx.deployVerticle(verticleClass); // same behavior as vert.x 2.x => deploy with classloader isolation
vertx.isolating().deployVerticle(verticleClass); // deploy with classloader isolation
vertx.isolating(withCurrentCLParent()).deployVerticle(verticleClass); // deploy with classloader isolation and current CL as parent
vertx.isolating(usingCustomCLMaker()).deployVerticle(verticleClass); // deploy with classloader isolation using a custom classloader factory

vertx.flat().deployVerticle(verticleClass); // deploy in the same CL

Of course this kind of API could be tweaked in a different ways. And could be reused for other part of the API to enable additional features.

Thoughts ?

-- Brice

[Tim Fox]

On 25/04/14 09:47, petermd wrote:

Rather then trying to enum the permutations, how about just creating a VerticleGroup concept that incorporates a shared ClassLoader eg

vertx.deployVerticle(class)

vertx.deployVerticle(class,group)

Nice idea

this way you don't allow custom classloaders, but the deploying master verticle can define isolation groups that match their requirements. it could also be used to assign other resources (eg each group could have its own workerverticle threadpool) that might also need to be configured independently for third-party verticles.

nb still wondering if the problems people have with classloaders are because they are trying to share / compare instances inside the VM. since that's bad practice, won't work in a cluster etc, perhaps the default should be still be isolated classloader (per verticle class) with the option to share the classloader available only for those who need it?

-Peter

On Friday, 25 April 2014 07:52:22 UTC+1, Dean Pehrsson-Chapman wrote:

How about:

vertx.deployVerticle(verticleClass, ClassloaderIsolation.FLAT) ;

vertx.deployVerticle(verticleClass, ClassloaderIsolation.ISOLATED); 

vertx.deployVerticle(verticleClass, ClassloaderIsolation.ISOLATED_INCLUDE_CURRENT); 

vertx.deployVerticle(verticleClass); //default - ClassloaderIsolation.FLAT 

I think that would give all the functionality we currently have (but people would need to be explicit about it), and stops people using their own wonky classloaders and expecting you to support.

--

[Tim Fox]

On 24/04/14 22:52, Matthias Ohlemeyer wrote:

Are these assumptions correct? If the module system goes away, with it goes mod.json, the ability to include the resources of other modules, the module registry, automatic installation of modules...

If resolving at build time, then including the resources of modules becomes unnecessary.

I thought that one of the strengths of the module system, is the ability to provide functionality for others to use, irrespective of the programming language it is written in.

Now, what happens in a world without Vert.x modules? Will a JavaScript developer have to use gem to install a Ruby verticle? (Will this be possible at all?) Will a java developer have to learn npm if he is interested in functionality provided today by a JavaScript module? Will reuse on the level of todays modules still be easy?

Hopefully it will be easier, as modules would just be plain jars, not zips with a mod.json, so no extra learning curve or having to handle them differently to any other jars.

Or will we have a Vert.x Java community, a Vert.x JavaScript community...

Please explain.

Am Donnerstag, 24. April 2014 14:45:16 UTC+2 schrieb Tim Fox:

The proposal to remove the module system and consequently the
classloader isolation in Vert.x 3.0 seems to have split people.. Some of
you would love to see it go in order to simplify things and others
really like the feature...

So, how about a compromise...

Let's say you do

vertx.deployVerticle(verticleClass)

By default this will simply run the verticle using the current
classloader - i.e. we have a single flat classpath in the application.

But if you want your verticle to be deployed isolated, then you can do
something like:

vertx.deployVerticle(verticleClass, isolated = true);

Then it will create a new classloader and instantiate the verticle using
that, and any other libraries loaded by that verticle will also be
loaded by that new classloader. So basically that verticle and anything
else it instantiates will live in its own new flat classpath.

That way we can remove the module system but still retain classloader
isolation, if required.

How does that sound?

--

[Jordan Halterman]

jars sounds like an extra learning curve in and of itself to me. In my office I work with some developers that don't normally work with the JVM, and Vert.x applications are essentially the only applications we even have that run on the JVM. We write our modules (Java, JS, and Python) in a manner that ensures other developers can collaborate on them without having to know or care about the JVM. They could care less how they're run. They Python/PHP/JS developers, and all they know is that they're working on Python and JS code and using the Python and JS Vert.x APIs, and that's a big reason why we adopted Vert.x in the first place - support for languages that non-JVM users know.

Sent from my iPhone

[Tim Fox]

On 27/04/14 10:43, Jordan Halterman wrote:

jars sounds like an extra learning curve in and of itself to me.

Why is it an extra learning curve? What I am suggesting is a simplification to the current module system...

[Tim Fox]

It's always much easier to criticise and be a naysayer than be constructive ;)

So, turning this around - what is your proposal? And the same question goes to Nick and Jordan.


On 25/04/14 14:53, Norman Maurer wrote:

Norman Maurer

 Same here…

[Jordan Halterman]

Well, I tried to respond to you and explain why it would make life more difficult, but I kind if grew fond of the idea in the process and deleted my response after I realized it was stupid. I think I misunderstood the benefits and realized it would be awesome to resolve dependencies at build time for many wonderful reasons, so I'm totally on board :-)

Like I said to your original Vert.x 3.0 post: I sort of like the current module system. I guess this was more of a "don't fix it if it ain't broke" thing, though I have always felt like the module system was lacking something that I couldn't quite put my finger on.

Now I'm kind of excited.

Sent from my iPhone

[Tim Fox]

Cool. Also, next week I'd like to put together a more detailed proposal for Vert.x 3.0, that we can iterate on.

[Tim Fox]

On 27/04/14 11:56, Jordan Halterman wrote:

Well, I tried to respond to you and explain why it would make life more difficult, but I kind if grew fond of the idea in the process and deleted my response after I realized it was stupid.

Jordan, your posts are never stupid.

[Jordan Halterman]

You didn't see what I wrote :-) I'm just having fun with myself! Look forward to seeing a more in depth proposal! 

Good stuff!

Sent from my iPhone

[Konstantyn Smirnov]

So, how should I deploy a verticle programmatically in 3.5.0 in isolated class-loader?

I tried using

vertx.deployVerticle( "groovy:$SomeVerticle.name", [ isolationGroup:'executor' ] as DeploymentOptions )

but it didn't change anything...

[Jez P]

http://vertx.io/docs/vertx-core/java/#_verticle_isolation_groups

Looks to me like you need to set isolation classes too