Vert.x 2/0 plan
434 views
Skip to first unread message
Tim Fox
Dec 5, 2012, 6:57:33 AM12/5/12
to ve...@googlegroups.com
Based on our recent discussions, I've written up a list of the tasks for
Vert.x 2.0. Please give your feedback.
This is somewhat different to the last one, so please read it again.
I intend to get started on the classloader/module system tasks ASAP.
Any volunteers for other tasks, please step up!
Vert.x 2.0
======
1. Module System / Class loader changes
I) Classloaders
Now, module classes will be loaded just once - each module type will
have its own classloader. Not one classloader for each module instance.
Module classloaders will be arranged in a directed graph where each
classloader has at least one parent.
The parents of any particular module classloader are:
a) The classloader of the module that deployed it OR the Vert.x app
classloader if it is a top level module
b) The classloaders of any modules that it includes (via the module
include mechanism).
When loading a class by a module, first we try the modules own
classloader then if not found we try the modules parents using a
bread-first search.
Since the parent classloader of top level modules will be the Vert.x app
classloader this means you will be able to add jars and classes to the
Vert.x classpath if they are used by many different modules in your app.
However this will be frowned upon because it breaks the module
encapsulation.
II) Nested modules
It's recognised that it would be useful for many deployments -
especially in a strictly controlled ops environment to be able to
package up an entire Vert.x application, including all modules that it
depends on into a self contained unit that could be deployed on a server
and run without having to install any dependencies at run-time.
To this, the user will package the application is a Vert.x module in the
standard way, with a controlling Verticle (e.g. app.js) as the main
verticle. The module will contain any other verticles and resources as
per normal.
We will also allow a module to contain its own 'mods' directory which
will contain any 3rd party modules that the application relies on.
We will change the module search path so that at run-time when looking
for a module, Vert.x first looks in any module 'mods' dir and loads
modules from there if found.
We will also augment the vertx command so you can run a module zip file
directly, e.g.
vertx run mymodule.zip
Would automatically install (to local mods) and vertx runmod a zip file
which contains a valid vertx module.
III) Language runtime instances.
Language runtime instances such as JRuby, Rhino, Jython etc can have a
large RAM overhead. In Vert.x 1.x each Verticle instance had it's own
instance of the runtime which reduces the number of verticle instances
that can be deployed, and can cause issues such as permgen exhaustion.
In Vert.x 2.0 will have only one instance of the runtime per module
type, not per module instance. So we'll have a 1-1 cardinality between
classloader and runtime instance.
This should improve scalability and start-up time. The down-side is
module instances of a specific module type won't be completely isolated.
IV) Maven repository
We should look at setting up a Nexus instance to host the Vert.x public
module repo.
This would allow users to manage the process of publishing modules
themselves instead of having to go through the core project.
Vert.x would simply look at that repo instead of the current public repo
and pull modules from there
Modules could be pushed to the Nexus repo as simple mod.zip files with a
corresponding pom.xml
For users that are Maven averse (like myself) we can provide a command
line tool takes a Vert.x module and constructs the pom.xml and whatever
else is needed to make it a valid Maven deployment artifact. This means
users won't have to worry about creating it manually, which is great
since the vast majority of it is redundant to Vert.x
If anyone has knowledge of setting up / hosting Nexus repos that would
be a great help!
V) Module core version.
Modules should be tied to a specific version of core, so we don't get
weird errors when someone tries to use an module with an incompatible
version of core.
2) Maven and Gradle integration
We need Maven and Gradle tasks for
I) Creating a "best-practice" Vert.x new project
II) Assembling a Vert.x module given the "best-practice" layout.
Some community members have already done some work in this area - we
should look at bringing that work into Vert.x project proper.
I suggest using standard Maven/Gradle conventions for source layout.
I suggest best practice for constructing a Vert.x application should be:
At least one module which has an application starter Verticle (e.g.
App.js, App.Groovy etc) which deploys and co-ordinates all other
verticles and 3rd party modules which are used by the application.
Larger Vert.x applications may be composed of multiple user modules, but
we should probably model each module as a single standard Maven/Gradle
subproject.
In the build we should have a configurable parameter which determines
whether when a module is built, the modules on which it depends are
pulled in as nested modules or not. This should be easily configurable
by the user.
III) Running a module
Maven/Gradle tasks for running a module (which call vertx run)
3) Simpler ways to run tests in-container
Pid has some JUnit annotations for Java - this is great.
We need some solution for non-Java languages too.
4) Management & monitoring
We need to ability to do the following on running production instances
I) See all instances running) See stats for all instances
II) Start/Stop/Restart instances
III) Deploy to a server?
IV) Nice management GUI (web based) to do all this.
To do III) and IV) We'll need some kind of daemon running on the
production servers (perhaps another Vert.x instance?)
5) Multi-threaded workers
Writing some kinds of worker verticles that use traditional Java APIs
such as JDBC is quite awkward since worker verticles are single
threaded. It would be much simpler to be able to write a multi-threaded
worker verticle which managed a JDBC pool directly. A multi-threaded
verticle could receive messages on the same handler instance concurrently.
This wouldn't be commonly used and wouldn't be the default, but would be
very useful in writing plugin modules for stuff like JDBC, other
database stuff, mailers etc.
6) Separate language support out into modules
This means users only download and install those language impls that
they need. It also makes it easier for users to provide their own
language implementations as modules, thus devolving centralised
responsibility for new language support.
7) HA support.
We need to implement some kind of supervisor pattern for detecting
failure and stopping/starting modules (Erlang style)
8) Various other smaller stuff including:
* Some improvements to the core API, e.g. HttpClient
* Upgrade to latest version of SockJS
* Upgrade to Netty 4
* Various github issues need to be solved
9) Promises/Deferred APIs
I spent some days looking into the feasibility of using
co-routines/continuations on top of the core async API in order to
provide an alternative direct-style programming model.
Unfortunately I don't think this is going to be possible. I looked at
both JavaFlow and Kilim but they don't fit well with the Vert.x model
where there's a lot of user code and 3rd party libraries in the path
that needs to have its bytecode rewritten. This makes it unfeasible.
I also looked at Lukas Stadler's MLVM coroutine patch. I think this is
the future for the JVM but it's a long way off getting into a stock JVM.
So for now, if we want to help users deal with an async API the best
thing we can do is provide (or point to) libraries that allow them to
compose their asynchronous flows in more easy to comprehend ways.
For Java we should look at either providing our own promises/deferreds
API but also look at what's out there already in case we can use
something or adapt something.
For JavaScript there are already solutions such as kaolan's async. We
should look at recommending/integrating something like that.
For other languages likewise.
But we need a story with some documentation and guidance about what we
recommend in this area.
Vert.x 2.0. Please give your feedback.
This is somewhat different to the last one, so please read it again.
I intend to get started on the classloader/module system tasks ASAP.
Any volunteers for other tasks, please step up!
Vert.x 2.0
======
1. Module System / Class loader changes
I) Classloaders
Now, module classes will be loaded just once - each module type will
have its own classloader. Not one classloader for each module instance.
Module classloaders will be arranged in a directed graph where each
classloader has at least one parent.
The parents of any particular module classloader are:
a) The classloader of the module that deployed it OR the Vert.x app
classloader if it is a top level module
b) The classloaders of any modules that it includes (via the module
include mechanism).
When loading a class by a module, first we try the modules own
classloader then if not found we try the modules parents using a
bread-first search.
Since the parent classloader of top level modules will be the Vert.x app
classloader this means you will be able to add jars and classes to the
Vert.x classpath if they are used by many different modules in your app.
However this will be frowned upon because it breaks the module
encapsulation.
II) Nested modules
It's recognised that it would be useful for many deployments -
especially in a strictly controlled ops environment to be able to
package up an entire Vert.x application, including all modules that it
depends on into a self contained unit that could be deployed on a server
and run without having to install any dependencies at run-time.
To this, the user will package the application is a Vert.x module in the
standard way, with a controlling Verticle (e.g. app.js) as the main
verticle. The module will contain any other verticles and resources as
per normal.
We will also allow a module to contain its own 'mods' directory which
will contain any 3rd party modules that the application relies on.
We will change the module search path so that at run-time when looking
for a module, Vert.x first looks in any module 'mods' dir and loads
modules from there if found.
We will also augment the vertx command so you can run a module zip file
directly, e.g.
vertx run mymodule.zip
Would automatically install (to local mods) and vertx runmod a zip file
which contains a valid vertx module.
III) Language runtime instances.
Language runtime instances such as JRuby, Rhino, Jython etc can have a
large RAM overhead. In Vert.x 1.x each Verticle instance had it's own
instance of the runtime which reduces the number of verticle instances
that can be deployed, and can cause issues such as permgen exhaustion.
In Vert.x 2.0 will have only one instance of the runtime per module
type, not per module instance. So we'll have a 1-1 cardinality between
classloader and runtime instance.
This should improve scalability and start-up time. The down-side is
module instances of a specific module type won't be completely isolated.
IV) Maven repository
We should look at setting up a Nexus instance to host the Vert.x public
module repo.
This would allow users to manage the process of publishing modules
themselves instead of having to go through the core project.
Vert.x would simply look at that repo instead of the current public repo
and pull modules from there
Modules could be pushed to the Nexus repo as simple mod.zip files with a
corresponding pom.xml
For users that are Maven averse (like myself) we can provide a command
line tool takes a Vert.x module and constructs the pom.xml and whatever
else is needed to make it a valid Maven deployment artifact. This means
users won't have to worry about creating it manually, which is great
since the vast majority of it is redundant to Vert.x
If anyone has knowledge of setting up / hosting Nexus repos that would
be a great help!
V) Module core version.
Modules should be tied to a specific version of core, so we don't get
weird errors when someone tries to use an module with an incompatible
version of core.
2) Maven and Gradle integration
We need Maven and Gradle tasks for
I) Creating a "best-practice" Vert.x new project
II) Assembling a Vert.x module given the "best-practice" layout.
Some community members have already done some work in this area - we
should look at bringing that work into Vert.x project proper.
I suggest using standard Maven/Gradle conventions for source layout.
I suggest best practice for constructing a Vert.x application should be:
At least one module which has an application starter Verticle (e.g.
App.js, App.Groovy etc) which deploys and co-ordinates all other
verticles and 3rd party modules which are used by the application.
Larger Vert.x applications may be composed of multiple user modules, but
we should probably model each module as a single standard Maven/Gradle
subproject.
In the build we should have a configurable parameter which determines
whether when a module is built, the modules on which it depends are
pulled in as nested modules or not. This should be easily configurable
by the user.
III) Running a module
Maven/Gradle tasks for running a module (which call vertx run)
3) Simpler ways to run tests in-container
Pid has some JUnit annotations for Java - this is great.
We need some solution for non-Java languages too.
4) Management & monitoring
We need to ability to do the following on running production instances
I) See all instances running) See stats for all instances
II) Start/Stop/Restart instances
III) Deploy to a server?
IV) Nice management GUI (web based) to do all this.
To do III) and IV) We'll need some kind of daemon running on the
production servers (perhaps another Vert.x instance?)
5) Multi-threaded workers
Writing some kinds of worker verticles that use traditional Java APIs
such as JDBC is quite awkward since worker verticles are single
threaded. It would be much simpler to be able to write a multi-threaded
worker verticle which managed a JDBC pool directly. A multi-threaded
verticle could receive messages on the same handler instance concurrently.
This wouldn't be commonly used and wouldn't be the default, but would be
very useful in writing plugin modules for stuff like JDBC, other
database stuff, mailers etc.
6) Separate language support out into modules
This means users only download and install those language impls that
they need. It also makes it easier for users to provide their own
language implementations as modules, thus devolving centralised
responsibility for new language support.
7) HA support.
We need to implement some kind of supervisor pattern for detecting
failure and stopping/starting modules (Erlang style)
8) Various other smaller stuff including:
* Some improvements to the core API, e.g. HttpClient
* Upgrade to latest version of SockJS
* Upgrade to Netty 4
* Various github issues need to be solved
9) Promises/Deferred APIs
I spent some days looking into the feasibility of using
co-routines/continuations on top of the core async API in order to
provide an alternative direct-style programming model.
Unfortunately I don't think this is going to be possible. I looked at
both JavaFlow and Kilim but they don't fit well with the Vert.x model
where there's a lot of user code and 3rd party libraries in the path
that needs to have its bytecode rewritten. This makes it unfeasible.
I also looked at Lukas Stadler's MLVM coroutine patch. I think this is
the future for the JVM but it's a long way off getting into a stock JVM.
So for now, if we want to help users deal with an async API the best
thing we can do is provide (or point to) libraries that allow them to
compose their asynchronous flows in more easy to comprehend ways.
For Java we should look at either providing our own promises/deferreds
API but also look at what's out there already in case we can use
something or adapt something.
For JavaScript there are already solutions such as kaolan's async. We
should look at recommending/integrating something like that.
For other languages likewise.
But we need a story with some documentation and guidance about what we
recommend in this area.
pk
Dec 5, 2012, 1:07:32 PM12/5/12
to ve...@googlegroups.com
I am not sure if I missed something. Are we not going to have scala support in v2.0?
Thanks,
Pradeep
Tim Fox
Dec 5, 2012, 1:24:25 PM12/5/12
to ve...@googlegroups.com
To clarify, the list of tasks I posted refer to work that needs to be
done in Vert.x core.
Around the time of the 2.0 release it would also be great to have better
support for various things in new or enhanced modules, but modules
really follow a different life cycle.
In vert.x 2.0 adding a new language will be done by creating a module.
In terms of modules I would love to see around the time of Vert.x 2.0
1. Scala and Clojure support
2. Better AMQP support
3. Better RDMS support
4. Better redis support
5. Better Spring integration etc
etc
The new module and classloader system will make these things easier to do.
All these tasks are up for grabs, if anyone wants to volunteer, but
they're not part of Vert.x core
> --
> You received this message because you are subscribed to the Google
> Groups "vert.x" group.
> To view this discussion on the web, visit
> https://groups.google.com/d/msg/vertx/-/syak_yBQCoAJ.
> To post to this group, send an email to ve...@googlegroups.com.
> To unsubscribe from this group, send email to
> vertx+un...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/vertx?hl=en-GB.
--
Tim Fox
Vert.x - effortless polyglot asynchronous application development
http://vertx.io
twitter:@timfox
done in Vert.x core.
Around the time of the 2.0 release it would also be great to have better
support for various things in new or enhanced modules, but modules
really follow a different life cycle.
In vert.x 2.0 adding a new language will be done by creating a module.
In terms of modules I would love to see around the time of Vert.x 2.0
1. Scala and Clojure support
2. Better AMQP support
3. Better RDMS support
4. Better redis support
5. Better Spring integration etc
etc
The new module and classloader system will make these things easier to do.
All these tasks are up for grabs, if anyone wants to volunteer, but
they're not part of Vert.x core
> You received this message because you are subscribed to the Google
> Groups "vert.x" group.
> To view this discussion on the web, visit
> https://groups.google.com/d/msg/vertx/-/syak_yBQCoAJ.
> To post to this group, send an email to ve...@googlegroups.com.
> To unsubscribe from this group, send email to
> vertx+un...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/vertx?hl=en-GB.
--
Tim Fox
Vert.x - effortless polyglot asynchronous application development
http://vertx.io
twitter:@timfox
ddimensia
Dec 5, 2012, 2:16:52 PM12/5/12
to ve...@googlegroups.com
Is there any plan to stage these features in multiple releases? It'd be nice to see an iterative approach to getting all of these added rather than a big release held up by a few partially complete features. I guess things could always be cut later but I'd rather have access to some of these improvements sooner rather than wait for some that I can work around.
Pid
Dec 5, 2012, 5:28:52 PM12/5/12
to ve...@googlegroups.com
On 05/12/2012 19:16, ddimensia wrote:
> Is there any plan to stage these features in multiple releases? It'd be
> nice to see an iterative approach to getting all of these added rather
> than a big release held up by a few partially complete features. I
> guess things could always be cut later but I'd rather have access to
> some of these improvements sooner rather than wait for some that I can
> work around.
The bits I'm working on will land as soon as they are ready & where
> Is there any plan to stage these features in multiple releases? It'd be
> nice to see an iterative approach to getting all of these added rather
> than a big release held up by a few partially complete features. I
> guess things could always be cut later but I'd rather have access to
> some of these improvements sooner rather than wait for some that I can
> work around.
possible. Some of the JMX monitoring parts require additions to the
core, which may not happen in 1.x.
p
> > To post to this group, send an email to ve...@googlegroups.com
> <javascript:>.
> > To unsubscribe from this group, send email to
> > vertx+un...@googlegroups.com <javascript:>.
> <http://groups.google.com/group/vertx?hl=en-GB>.
>
>
> --
> Tim Fox
>
> Vert.x - effortless polyglot asynchronous application development
> http://vertx.io
> twitter:@timfox
>
>
> --
> Tim Fox
>
> Vert.x - effortless polyglot asynchronous application development
> http://vertx.io
> twitter:@timfox
>
> --
> You received this message because you are subscribed to the Google
> Groups "vert.x" group.
> To view this discussion on the web, visit
> https://groups.google.com/d/msg/vertx/-/EGi7fT3DaC4J.
> You received this message because you are subscribed to the Google
> Groups "vert.x" group.
> To view this discussion on the web, visit
> To post to this group, send an email to ve...@googlegroups.com.
> To unsubscribe from this group, send email to
> vertx+un...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/vertx?hl=en-GB.
--
[key:62590808]
> To unsubscribe from this group, send email to
> vertx+un...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/vertx?hl=en-GB.
--
Pid
Dec 6, 2012, 10:53:14 AM12/6/12
to ve...@googlegroups.com
On 05/12/2012 11:57, Tim Fox wrote:
> 4) Management & monitoring
>
> We need to ability to do the following on running production instances
>
> I) See all instances running) See stats for all instances
> II) Start/Stop/Restart instances
> III) Deploy to a server?
> IV) Nice management GUI (web based) to do all this.
>
> To do III) and IV) We'll need some kind of daemon running on the
> production servers (perhaps another Vert.x instance?)
I have a project underway for some of these parts:
> 4) Management & monitoring
>
> We need to ability to do the following on running production instances
>
> I) See all instances running) See stats for all instances
> II) Start/Stop/Restart instances
> III) Deploy to a server?
> IV) Nice management GUI (web based) to do all this.
>
> To do III) and IV) We'll need some kind of daemon running on the
> production servers (perhaps another Vert.x instance?)
http://github.com/swilliams-vmw/mod-management
p
--
[key:62590808]
Tim Yates
Dec 6, 2012, 10:58:26 AM12/6/12
to ve...@googlegroups.com
Could I request the ability to add your own ConcurrentMap to the Shared Data?
With Guava for example you can make a capacity limited LRU cache by importing com.google.common.collect.*
and then using the line:
new MapMaker().concurrencyLevel(1)
.weakValues()
.maximumSize(100)
.expireAfterWrite( 10, TimeUnit.SECONDS )
.makeMap()
It would be great to be able to tell SharedData to use this as one of its maps (with a given name). Or are there other rules that a SharedMap must abide by in order that it may be shared?
Tim
--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To post to this group, send an email to ve...@googlegroups.com.
To unsubscribe from this group, send email to vertx+unsubscribe@googlegroups.com.
Rick Mangi
Dec 6, 2012, 11:06:09 AM12/6/12
to ve...@googlegroups.com
Hey Pid,
What's the status of this tool?
Anything you can share beyond "A project summary goes here"?
:-)
-------------------------
Rick Mangi
SVP of Technology
twitter: @rmangi
www.broadcastr.com
Rick Mangi
SVP of Technology
twitter: @rmangi
www.broadcastr.com
Tim Fox
Dec 6, 2012, 11:10:00 AM12/6/12
to ve...@googlegroups.com
On 06/12/12 15:58, Tim Yates wrote:
> Could I request the ability to add your own ConcurrentMap to the
> Shared Data?
>
> With Guava for example you can make a capacity limited LRU cache by
> importing com.google.common.collect.*
> and then using the line:
>
> new MapMaker().concurrencyLevel(1)
> .weakValues()
> .maximumSize(100)
> .expireAfterWrite( 10, TimeUnit.SECONDS )
> .makeMap()
>
> It would be great to be able to tell SharedData to use this as one of
> its maps (with a given name). Or are there other rules that a
> SharedMap must abide by in order that it may be shared?
They main rule is they can't contain mutable data
> Could I request the ability to add your own ConcurrentMap to the
> Shared Data?
>
> With Guava for example you can make a capacity limited LRU cache by
> importing com.google.common.collect.*
> and then using the line:
>
> new MapMaker().concurrencyLevel(1)
> .weakValues()
> .maximumSize(100)
> .expireAfterWrite( 10, TimeUnit.SECONDS )
> .makeMap()
>
> It would be great to be able to tell SharedData to use this as one of
> its maps (with a given name). Or are there other rules that a
> SharedMap must abide by in order that it may be shared?
> To unsubscribe from this group, send email to
> vertx+un...@googlegroups.com
> <mailto:vertx%2Bunsu...@googlegroups.com>.
> --
> You received this message because you are subscribed to the Google
> Groups "vert.x" group.
> To post to this group, send an email to ve...@googlegroups.com.
> To unsubscribe from this group, send email to
> vertx+un...@googlegroups.com.
> You received this message because you are subscribed to the Google
> Groups "vert.x" group.
> To post to this group, send an email to ve...@googlegroups.com.
> To unsubscribe from this group, send email to
Tim Yates
Dec 6, 2012, 11:12:21 AM12/6/12
to ve...@googlegroups.com
On 6 December 2012 16:10, Tim Fox <timv...@gmail.com> wrote:
On 06/12/12 15:58, Tim Yates wrote:They main rule is they can't contain mutable data
Could I request the ability to add your own ConcurrentMap to the Shared Data?
With Guava for example you can make a capacity limited LRU cache by importing com.google.common.collect.*
and then using the line:
new MapMaker().concurrencyLevel(1)
.weakValues()
.maximumSize(100)
.expireAfterWrite( 10, TimeUnit.SECONDS )
.makeMap()
It would be great to be able to tell SharedData to use this as one of its maps (with a given name). Or are there other rules that a SharedMap must abide by in order that it may be shared?
Ahhh, hence the calls to Checker in the SharedMap code...
Pid *
Dec 6, 2012, 11:17:42 AM12/6/12
to ve...@googlegroups.com
Have a look at the agent subproject.
Tim Yates
Dec 6, 2012, 11:20:29 AM12/6/12
to ve...@googlegroups.com
It would be cool if there were a setMap( 'name', ConcurrentMap ) method, but have it lathered in warnings...
Then you could also do things like (in Groovy)
getMap( 'name ).avalue = [ a: 1 ].asImmutable()
And store more complex values in there..
Anyway, just an idea :-)
Cheers
Tim
bytor99999
Dec 10, 2012, 1:59:44 PM12/10/12
to ve...@googlegroups.com
Love the list.
About sharedData, can we have it allow other types of objects? I know you have the immutable parts, but the values should be able to take other types. We do plan on using Redis for sharedData for now since we can't put such objects in, and it is nice that on the list you have better Redis support.
Thanks
Mark
Reply all
Reply to author
Forward
0 new messages