Vert.x 3.0 update

[Tim Fox]

Vertites,

I was thinking of putting together an alpha, or "preview" release for
Vert.x 3.0 today, then I thought, well, if you want to see what is going
on you don't need to download a tar.gz distro and install it, all you
need to do is look at an example Maven project - all the Vert.x
dependencies are already in oss.sonatype.org as snapshots. Creating a
tar.gz doesn't really add much at this point. So I'm not going to create
a "release", but I will explain what is new in Vert.x 3.0 and explain
how you can explore this.

We can create more updates like this as things progress.

I include below a list of the main changes in Vert.x 3.0 (amongst other
things) to date, compared to Vert.x 2.x. This is not an exhaustive list,
there have been many, many small changes, fixes and new features, so
I've just highlighted some of the more significant ones.

* Code location

Vert.x 3.0 core is in the main Eclipse project:
https://github.com/eclipse/vert.x (master branch)

The rest of Vert.x 3.0 is under the new Vert-x3 umbrella organisation in
GitHub: https://github.com/vert-x3/

* No more module system

The Vert.x module system has gone. Now you create your verticles and
package them into standard java jars. These jars can be pushed to Maven
repositories (or bintray) just like any Maven artifact.

When you use these artifacts in your application you specify them as
standard Maven dependencies in your project and they are resolved at
build-time, not at run-time like in Vert.x 2.0.

Non Java verticles (e.g. JavaScript) can also be packaged in jars and
pushed as Maven artifacts. We will also support resolving in other ways
and from other places (e.g. at run-time and from npm modules) before
3.0.final.

We recommend package your application into [a set of] of fat executable
jars which contain all the dependencies they need to run. The example
project (see bottom of this document) shows an example of that.

* Code generation of other language APIs

One of the big pain points of Vert.x 2.x development was keeping all the
other language APIs in sync as changes occur in the Java core APIs, as
it was a manually process. As we have a small team, this was becoming
unsustainable and hard to manage.

In Vert.x 3.0 we maintain just the core Java API and we will generate
other language APIs from that.

Generation works by inspecting the Java source of the core APIs before
compile and constructing an internal model from that. This is then fed
into a MVEL2 template (one for each language) which then outputs the
code in other languages.

In order for codegen to be feasible we specify a set of constraints that
any API that we run codegen on must follow. The codegen project details
these constraints:

https://github.com/vert-x3/codegen

So far we have JavaScript and Groovy more or less complete, and Julien
is currently working on Ceylon. Other languages will follow.

* Use of Maven for the Vert.x builds

We now use Maven, not Gradle to build the Vert.x main project and the
"ext" projects. Please note that we do not mandate Maven for your own
Vert.x 3.0 projects - you shoud be able to use whatever build tool you
want for that (e.g. Gradle). Vert.x 3.0 projects generally have a very
simple setup (much simpler than Vert.x 2.0).

* Java 8 only

Vert.x 3.0 is Java 8 only. This is to take advantage of new language
features in Java 8, the most important of which is Lambdas which make
developing against event based APIs so much nicer than in previous
versions of Java. We also chose Java8 so we can use Nashorn - the new
high performance JavaScript engine that it contains.

* Flat classpath by default

When deploying verticles, there is a simple single flat classpath (by
default). This should greatly simplify embedding and debugging. If you
do wish to deploy verticles with classloader isolation this is still
available as an option, but it's considered an edge case now.

* Verticle factory simplification

There is no more `langs.properties`. Verticle factories are loaded from
the classpath using the service loader pattern. Verticle factories can
also be registered and unregistered programmatically.

* Deployment of Verticle instances

You can now instantiate verticles and deploy verticle *instances*
programmatically.

* Warnings if you block an event loop

You will now see warnings in the logs if you inadvertently (or
deliberately!) block an an event loop, so you can identify and fix the
issue more quickly. You will also see warnings if you block a worker
thread for too long.

* Removal of platform manager

The platform manager API has been removed, and methods for deploying
verticles have moved to the Vertx interface. The API for deploying
verticles is much simpler, so this should simplify things when embedding.

* Programmatic cluster manager

Cluster managers can now be specified programmatically

* Clustered shared data

Vert.x now supports a distributed Map API which works across the
cluster. You can put data in at one Vert.x node and read it from another.

We also provide an asynchronous cluster wide lock implementation, and
asynchronous cluster-wide counters. These are very useful building
blocks for distributed applications.

* Completely rewritten HTTP client

The HTTP client has been completely rewritten with much saner behaviour
for opening and closing connections, pipe-lining and keep alive.

* WebSocket API improvements

The WebSocket API has been improved so you can now send and receive
WebSocket frames.

* Improvements to SSL/TLS

The new SSL API allows you to configure certificates and keys in several
ways, not just with Java key stores. For example, with Strings and
Buffers (similar to Node.js).

We also support certificate revocation lists and specification of cipher
suites.

* Event bus API improvements

When registering a handler you now receive a Registration object which
you can later use to unregister.

We also now support custom codecs on the event bus so you can send any
object you want across the event bus (e.g. a POJO) as long as you write
a codec for it. We also support receiving messages as a different type
to what was sent, e.g. you could send a buffer which contains some BSON
and receive it as a POJO representing that BSON.

* Event bus proxies

You can register service interfaces with the event bus, then you can
interact with the service from a completely different verticle using a
proxy for the service.

* The 'ext' stack

https://github.com/vert-x3/ext

Vert.x extensions live in the `ext` project. This is functionality which
is not part of Vert.x core but contains useful stuff that people need to
write real applications with Vert.x. You can think of this plus Vert.x
core comprising the Vert.x "stack".

So far, ext just contains a few things including: SockJS, RouteMatcher,
and MongoService and Reactivestreams but will contain many other
services before 3.0.final.

A lot of the work in Vert.x 3.0 is in creating this stack.

* MongoService

This is a component of the ext stack. It's an API that lets you interact
with a MongoDB database. It uses the experimental 100% Async driver from
the MongoDB folks. You can deploy it as a verticle and interact with it
over the event bus using a proxy.

* ReactiveStreams

This is an implementation of http://www.reactive-streams.org/

* Use of options classes

We now use options classes widely throughout Vert.x in order to
configure objects. This means a lot of the setter methods on interfaces
such as NetClient, NetServer, HttpClient and HttpServer have been removed.

* Example project

I've put together an example Maven project which shows how you might
write a simple application with Vert.x 3.0.

It's a simple web application that uses SockJS and also has a REST API.
It has a JavaScript main verticle which starts up the app and a Java
WebServer and a Groovy stock ticker.

https://github.com/vert-x3/example-proj

* What's next?

** Most of Vert.x 3.0 core is done but there is a some more work to do
** More work on codegen
** Codegen templates for other language APIs (Scala, Ruby etc)
** Documentation, including JavaDoc/Asciidoc.
** The rest of the ext stack. This is where most of the work is.

[Steven Pousty]

Thanks for the update Tim!

Has there been any change to the way people declare dependencies for their projects? For example how do I pull in external libraries for a JavaScript application? Can I use npm or do I need to bundle it all up? Same for python?

Thanks
Steve

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Nicolaas Frederick Huysamen]

Hi Tim (and team). Incredible work on Vert.x 3. I have been playing around with it a bit and I must say a huge well done. You guys have literally taken everything I did not like about Vert.x 2 and gave it an intuitive alternative. Seriously, great work guys!

[qsys]

Amazing job! Although I have some questions (concerning the services, class loading etc), I'm pretty sure these things will be clear at the right time. Anyway, I'm really looking forward to using vertx 3.0.

Thx!
qsys

Op dinsdag 16 september 2014 20:06:22 UTC+2 schreef Tim Fox:

[Jordan Halterman]

I also have been playing around with Vert.x 3 and even made a Vert.x 3 event bus protocol for CopyCat. Actually, proxies are great for that particular use case as you can call state machine commands via the proxy, so the state machine feels like a local object. It's pretty awesome!

Tim, I don't know if you saw my tweet, but I can definitely work on the Python template if needed.

Jordan

> --
> 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.

[Jordan Halterman]

Also, I know this is a little off topic, but once I get some extra free time I plan to play with the idea of a py4j based Python implementation for Vert.x. I've used py4j in Apache Spark and the benefits of using CPython over Jython are enormous for average Python developers. That would significantly aid in the usability and compatibility of Python in Vert.x. But what I'm curious about is performance.

Jordan

> On Sep 16, 2014, at 11:06 AM, Tim Fox <purpl...@gmail.com> wrote:
>

[Tim Fox]

On 19/09/14 07:58, Jordan Halterman wrote:
> I also have been playing around with Vert.x 3 and even made a Vert.x 3 event bus protocol for CopyCat. Actually, proxies are great for that particular use case as you can call state machine commands via the proxy, so the state machine feels like a local object. It's pretty awesome!
>
> Tim, I don't know if you saw my tweet, but I can definitely work on the Python template if needed.

I didn't see your tweet, but that would be awesome.

I suggest looking at the JavaScript and Groovy codegen templates to see
how they work:

https://github.com/vert-x3/vertx-js
https://github.com/vert-x3/vertx-groovy

The common codegen stuff is here:

https://github.com/vert-x3/codegen

And feel free to ping me or Julien if you have any questions.

[Tim Fox]

On 19/09/14 08:06, Jordan Halterman wrote:
> Also, I know this is a little off topic, but once I get some extra free time I plan to play with the idea of a py4j based Python implementation for Vert.x. I've used py4j in Apache Spark and the benefits of using CPython over Jython are enormous for average Python developers. That would significantly aid in the usability and compatibility of Python in Vert.x.

+100

> But what I'm curious about is performance.

Maybe put together a few simple benchmarks and compare the two?

[Jordan Halterman]

Yep I can do that. I'll try it out and share the results so we can decide how feasible it is.

[Asher Tarnopolski]

hi tim,

you are doing a great work, i'm really looking forward for vert.x3.

i have a question regarding high availability in v3: is automatic failover feature will be still available in a modul-less environment?

thanks  

[Jordan Halterman]

Yes HA is still in Vert.x 3 and I think it essentially works the same way.

[Jordan Halterman]

I started working on codegen for Python today along with a VerticleFactory for Py4J. Basically, I got carried away with the codegen stuff and eventually got the Python template generating valid Python packages and modules. There are some optimizations that still need to be done - Pythons mixture of positional args and named args makes generating clean and performant logic for overloaded methods pretty challenging, but I think code generation will actually lead to much more flexible use if Python's arguments than is seen in most projects. Basically, all overloaded methods will support arbitrary combinations of positional and keyword arguments.

I should be able to clean up the template tomorrow and then finish the Py4J implementation and port the Jython implementation this week. Tim, if you're interested in setting up a Python repo in the vert-x3 org I'm interested in pushing to it :-)

On Sep 21, 2014, at 3:56 AM, Asher Tarnopolski <ata...@gmail.com> wrote:

[Tim Fox]

Wow, that was fast!

/me has suspicions that Jordan is in fact an AI, not a human ;)

[sANTo L]

Great work!

Is there any documentation already on how to migrate a 2.x application to 3.x ?

Santo

[Jordan Halterman]

I think the documentation is lacking right now, but I might be willing to write some migration docs once I'm done with the Python and PHP templates (in a couple weeks) if it's not already done before then. The problem is, we'll need those docs for each language. Fortunately, though, most of the API changes are things like Options objects with the biggest structural change being the removal of the container.

[sANTo L]

Hi Jordan,

That would be great!

And I suppose the module system - or better, the lack thereof - is also an important change regarding the migration of existing applications ?

Santo

[Jordan Halterman]

Oh yeah :-) That's obviously relevant!

I'm sort of interested to see what users come up with in terms of packaging and cluster management with the module system gone. I certainly intend to do some experimentation with Docker.

[sANTo L]

Yeah, docker containers are definitely a very interesing topic in this regard.

Actually I'm experimenting with running a vert.x app (2.x for now) in docker containers as we speak :-)

I have it running - with some rough edges - for a single node and have it almost working for a multi-node setup, thanks to the help of Nick Scavelli.

For now all settings are applied manually, but of course it would be nice if that could be automated in some way.

And of course it would be nice to be able to use this for 3.x as well.

Santo

[Jordan Halterman]

Wow awesome!

[Lenders]

Hi Tim,

Now we've got rid of modules, is it still possible to dynamically deploy verticles at runtime? this was one of the main drivers with us moving forward with vertx.

If this is not possible in the core vertx I'd like to try and contribute something that would enable this but at the moment I wouldn't know where to start; has vertx still got classloader separation etc?

Peter

On Tuesday, 16 September 2014 20:06:22 UTC+2, Tim Fox wrote:

Disclaimer: This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited. 

[Jordan Halterman]

You can still deploy verticles programmatically at runtime.

Also, IIRC Vert.x 3 supports classloader isolation, but not by default. It is provided in options through "isolation groups"

--

[Jordan Halterman]

I've made the initial work on the Python language public:

https://github.com/kuujo/vertx-python/blob/master/src/main/resources/vertx_python/template/python.templ

Of course, I don't really want in my account and it an be moved to the vert-x3 org whenever :-)

Most of the project is hacked together right now, but the template linked above generates some pretty optimal Python code. Juggling positional and keyword arguments with overloaded methods requires a lot of confusing logic, but the Java API constraints made it possible.

I did find a few bugs in the codegen project (mostly related to string parsing). I'll submit a PR when I get a chance.

On the Py4J front, I was able to get Py4J working fine. However, the implementation is very rudimentary. I'll have to do some work on the Python side to create JVM subprocesses when a new Vertx instance is created - right now it only works through verticle deployment. But starting a JVM subprocess from Python will mean Vert.x can be run directly from CPython which I think is just swell :-)

Also, I had a difficult time organizing the generated Python packages/modules/classes ideally (multiple classes per module, creating usable package hierarchies, etc), but I suspect that I'm just not doing it right :-( But I don't think now's the time to go in to that, I'm sure I'll catch up with you on it later.

On Sep 22, 2014, at 4:31 AM, sANTo L <santo...@gmail.com> wrote:

[Julien Viet]

On 23 Sep 2014 at 09:51:35, Jordan Halterman (jordan.h...@gmail.com) wrote:
> I've made the initial work on the Python language public:
> https://github.com/kuujo/vertx-python/blob/master/src/main/resources/vertx_python/template/python.templ
>
> Of course, I don't really want in my account and it an be moved to the vert-x3 org whenever
> :-)

great job Jordan!

>
> Most of the project is hacked together right now, but the template linked above generates
> some pretty optimal Python code. Juggling positional and keyword arguments with overloaded
> methods requires a lot of confusing logic, but the Java API constraints made it possible.
>
> I did find a few bugs in the codegen project (mostly related to string parsing). I'll submit
> a PR when I get a chance.
> 
> On the Py4J front, I was able to get Py4J working fine. However, the implementation is
> very rudimentary. I'll have to do some work on the Python side to create JVM subprocesses
> when a new Vertx instance is created - right now it only works through verticle deployment.
> But starting a JVM subprocess from Python will mean Vert.x can be run directly from CPython
> which I think is just swell :-)

that’s how I proceed too, step by step, starting with some rudimentary but that works. 

>
> Also, I had a difficult time organizing the generated Python packages/modules/classes
> ideally (multiple classes per module, creating usable package hierarchies, etc),
> but I suspect that I'm just not doing it right :-( But I don't think now's the time to go in
> to that, I'm sure I'll catch up with you on it later.
>

sure, we can discuss about that and see what we can do to improve this.

[Tim Fox]

On 23/09/14 08:51, Jordan Halterman wrote:

I've made the initial work on the Python language public:

https://github.com/kuujo/vertx-python/blob/master/src/main/resources/vertx_python/template/python.templ

Of course, I don't really want in my account and it an be moved to the vert-x3 org whenever :-)

Jordan - I've given you rights on the vert-x3 umbrella so you can move the project there :)

[Jordan Halterman]

Awesome thanks!

[Paulo Lopes]

Hi Tim,

Finally I've got some time to work on mod-redis I managed to port it to maven, and use the codegen API, i have already around 130 working tests and the basic functionality is already working.Now my question is, before i was working on:

https://github.com/vert-x/mod-redis

and the new code is on:

https://github.com/vert-x/mod-redis/tree/feature/vertx3

but if i understand it right it should go to the ext project? how can i move my stuff there?

Thanks!

On Tuesday, September 16, 2014 8:06:22 PM UTC+2, Tim Fox wrote:

[Julien Viet]

Hi Paulo,

that sounds like an awesome work you have done.

I would like to know if your tests requires an external database setup or if the tests can start a local database for the duration of the tests.

That would make adoption in ext much easier.

--
Julien Viet
www.julienviet.com

[pml...@gmail.com]

Hi, they require a redis server already running...

[Julien Viet]

we mongodb tests in ext we rely on:

- flapdoodle embed mongo stuff so any developer can run tests without a particular setup
- MongoHQ provided by Cloudbees for the CI

For the Vert.x 2 redis mod, in Cloudbees config I can see a script that download Redis via wget and run a redis-server command.

Perhaps we could use this maven plugin https://github.com/r351574nc3/redis-maven-plugin to achieve something for developers.

--
Julien Viet
www.julienviet.com

[Tim Yates]

Or there's https://github.com/kstyrc/embedded-redis

Not tried it, but looks like it just might work

[Nicolaas Frederick Huysamen]

Would it be possible to have codecs also available to proxied events?

[Paulo Lopes]

On Friday, October 3, 2014 2:00:23 PM UTC+2, Julien Viet wrote:

we mongodb tests in ext we rely on:

- flapdoodle embed mongo stuff so any developer can run tests without a particular setup
- MongoHQ provided by Cloudbees for the CI

For the Vert.x 2 redis mod, in Cloudbees config I can see a script that download Redis via wget and run a redis-server command.

Yes i added that, it was the "official" cloudbees way. If we can run the same script that is all i need to run the tests, otherwise i need to look into these maven plugins which i've no idea how to configure...
 

[Julien Viet]

How about I try configuring it for you ?

--
Julien Viet
www.julienviet.com

On 6 Oct 2014 at 14:12:17, Paulo Lopes (pml...@gmail.com) wrote:
>
>
> On Friday, October 3, 2014 2:00:23 PM UTC+2, Julien Viet wrote:
> >
> > we mongodb tests in ext we rely on:
> >
> > - flapdoodle embed mongo stuff so any developer can run tests without a
> > particular setup
> > - MongoHQ provided by Cloudbees for the CI
> >
> > For the Vert.x 2 redis mod, in Cloudbees config I can see a script that
> > download Redis via wget and run a redis-server command.
> >
>
>
> Yes i added that, it was the "official" cloudbees way. If we can run the
> same script that is all i need to run the tests, otherwise i need to look
> into these maven plugins which i've no idea how to configure...
>
>
> >
> > Perhaps we could use this maven plugin
> > https://github.com/r351574nc3/redis-maven-plugin to achieve something for
> > developers.
> >
> > --
> > Julien Viet
> > www.julienviet.com
> >
> >
> > On 3 Oct 2014 at 13:46:03, pml...@gmail.com (

[Julien Viet]

Hi Paulo,

I managed to get a Redis server managed for the tests

For the short story, I tried to use the Maven plugins cited before, both are based on a Java/Netty implementation of the Redis protocol. Many tests were failing, some easy to accommodate, some due to different behaviour between implementations. After searching a bit I found a simple wrapper of Redis and used it.

I pushed the work here:

https://github.com/vietj/mod-redis/tree/feature/vertx3

On my machine there are a couple of tests with TTL failing randomly (https://gist.github.com/vietj/8ca0bf43895248c51a2c), so I have a couple of questions:

- can you try to run the testsuite on your machine several times and see what happens
- perhaps such tests should be tweaked to use comparison instead of equality ?

--
Julien Viet
www.julienviet.com

[Paulo Lopes]

Hi,

Thanks i've merged your stuff, oddly on my machine all tests pass, my OS is ubuntu 14.04 64bit, oracle JVM, and redis 2.8.4

What i noticed now is that tests used to run in a couple of seconds and with the latests snapshots from vert.x core they take like a second per test...

Did anything changed on the netsocket side of things?

[Julien Viet]

can we tweak the tests so they pass on other OS too ?



--
Julien Viet
www.julienviet.com

[Paulo Lopes]

On di, 2014-10-07 at 10:39 +0200, Julien Viet wrote:
> can we tweak the tests so they pass on other OS too ?

I've increased the delays (double) so it should work, at least my poor
AMD A8 laptop can run the tests over and over without problems...

What i now notice is that tests are slooowwww, the whole test suite on a
real redis would run in a couple of seconds and now it takes several
minutes (like 1 sec per test)...

This is quite stange since i noticed this just by fetching new snapshots
from io.vertx...


>
>
>

[Julien Viet]

you can run the test with -Dhost= and/or -Dport= to disable the Redis startup and use your existing Redis. This can be added I think in your .m2/settings.xml to always use your local DB.

Still having this failure, does it make sense to you ?

java.lang.AssertionError: expected:<1> but was:<2>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:743)
at org.junit.Assert.assertEquals(Assert.java:118)
at org.junit.Assert.assertEquals(Assert.java:555)
at org.junit.Assert.assertEquals(Assert.java:542)
at io.vertx.test.core.AsyncTestBase.assertEquals(AsyncTestBase.java:186)
at io.vertx.test.redis.RedisServiceTest.lambda$null$169(RedisServiceTest.java:1391)
at io.vertx.test.redis.RedisServiceTest$$Lambda$221/479605092.handle(Unknown Source)
at io.vertx.redis.impl.AbstractRedisService.lambda$send$2(AbstractRedisService.java:255)
at io.vertx.redis.impl.AbstractRedisService$$Lambda$13/741390111.handle(Unknown Source)
at io.vertx.redis.impl.RedisConnection.handleReply(RedisConnection.java:182)
at io.vertx.redis.impl.ReplyParser.handle(ReplyParser.java:151)
at io.vertx.redis.impl.ReplyParser.handle(ReplyParser.java:6)
at io.vertx.core.net.impl.NetSocketImpl.handleDataReceived(NetSocketImpl.java:291)
at io.vertx.core.net.impl.VertxNetHandler.lambda$channelRead$44(VertxNetHandler.java:43)
at io.vertx.core.net.impl.VertxNetHandler$$Lambda$15/1502995784.run(Unknown Source)
at io.vertx.core.impl.ContextImpl.lambda$wrapTask$33(ContextImpl.java:234)
at io.vertx.core.impl.ContextImpl$$Lambda$8/1637693175.run(Unknown Source)
at io.vertx.core.impl.ContextImpl.execute(ContextImpl.java:144)
at io.vertx.core.net.impl.VertxNetHandler.channelRead(VertxNetHandler.java:43)
at io.vertx.core.net.impl.VertxNetHandler.channelRead(VertxNetHandler.java:32)
at io.vertx.core.net.impl.VertxHandler.channelRead(VertxHandler.java:141)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:333)
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:319)
at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:787)
at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:130)
at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:511)
at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:468)
at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:382)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:354)
at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116)
at java.lang.Thread.run(Thread.java:745)


--
Julien Viet
www.julienviet.com

[Paulo Lopes]

On di, 2014-10-07 at 21:15 +0200, Julien Viet wrote:
> you can run the test with -Dhost= and/or -Dport= to disable the Redis startup and use your existing Redis. This can be added I think in your .m2/settings.xml to always use your local DB.
>
> Still having this failure, does it make sense to you ?
>
> java.lang.AssertionError: expected:<1> but was:<2>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:743)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:555)
> at org.junit.Assert.assertEquals(Assert.java:542)
> at io.vertx.test.core.AsyncTestBase.assertEquals(AsyncTestBase.java:186)
> at io.vertx.test.redis.RedisServiceTest.lambda$null$169(RedisServiceTest.java:1391)

I don't have that assertion at that line, so i guess this is some older
version, can you check against the current git, since i already changed
the ttl test to expect longer ttls for slower machines...

[Julien Viet]

my bad, I did not merge the branch correctly.

now it passes with your change.



--
Julien Viet
www.julienviet.com

[Billy Yarosh]

Looks like some solid changes are coming for Vert.X 3. Ridding of modules looks like it simplifies a lot of the under the hood work. Providing tooling and libraries will be much easier as well.

I have one concern, and was wondering how auto-redeploy will work if all verticles are packaged jars and compile time dependencies? 

[Trevor S]

Interestingly, 

   Since one of my vehicles loads spring and intializes db pools, etc, auto-redelpoy didn't turn out to be so useful of a timesaver for me or my team.  its easy enough to click the 'restart' button in my intellij.  and without initializer startup code that takes a while, vertx starts up really fast already.  Web developers on my team just run the vertx app, and when they  refresh the browser, .js/.html/.css is re-read by the file sender set up at that route.

ps, have a look at JRebel (i haven't used) : http://zeroturnaround.com/forums/topic/jrebel-and-vert-x/    --> solutions like JRebel seem more possible without the module system.

[Billy Yarosh]

I find auto-redeploy more useful for a production deploy. In our case, we have several modules with their own HTTP server. From there, they coordinate their own verticles. There is a parent module that loads each domain module and coordinates the startup of the Vert.x instance. 

With the create-module-link command and the use of auto-redeploy, we can manually make hotfixes and code updates to production without ever seeing any real downtime. This eliminates a maintenance period and support continuous delivery.

Without a module system, this setup becomes much more complicated and the best case is to precompile a fat jar of verticles and drop that on the production server. It would force a small amount of down time during maintenance windows, and a redeploy with any hotfix changes.

 I understand why the module system is flawed as it makes packaging shared libraries and Vert.x extensions runtime dependencies. This is not practical and makes development difficult. There are plenty of build tools that have dependency management so I understand why Vert.x is moving away from modules. I was sold on modularity, and it will be difficult to get passed the usefulness it bodes in production for our use case.

[Oren Shvalb]

May I propose something that I really would like to see:

I would like the option of removing subscribers before doing a publish!

In my app I have an address that different clients subscribe and at some point in the server's flow I would like to unregister a specific client but still be able to use publish method!

I know I can implement this by using unique address for each client...

but having this as option in Vert.x would improve api and will save many developers the need to create a workaround themselves.

What do you think??

[Tim Fox]

On 12/01/15 16:36, Oren Shvalb wrote:

May I propose something that I really would like to see:

I would like the option of removing subscribers before doing a publish!

In my app I have an address that different clients subscribe and at some point in the server's flow I would like to unregister a specific client but still be able to use publish method!

How would you specify which subscriber you wanted to unregister using this new API?

[Oren Shvalb]

upon client subscribing an address the server '
handlePostRegister' is called with a unique id which server can associate to user's entity.

and when server would like to unsubscribe the specific user then it simply invoke 'unsubscribe' with the unique identifier he already stored.

it's up to the developer to store the registration's unique identifier at the server side.

Makes sense?

[Jordan Halterman]

The problem I have with this is that it's a significant API change that serves a rare use case, and it doesn't particularly solve any problems that can otherwise be solved with messaging patterns. Additionally, it allows verticles to impact each other's state without them knowing. In other words, I have no idea if/when my handler was unregistered by some other verticle, whereas message passing with unique IDs allows the side that registered the handler to at least perform the unregistration itself too. 

Also, as you mentioned, the server still has to be informed of the unique ID which requires message passing anyways.

Sent from my iPhone

[Oren Shvalb]

I beg to differ regarding how rare it is....Think about every chat server with rooms that people enter\leave rooms, every server that have the basic functionality of registration\unregister can use this feature and not making his own mechanism with unique address generation.

You would be surprised how useful it can be!!

It's hard for me to argue about the complexity of doing this...so I guess you are probably right...

It's a proposal that could really really help a lot of developers because the management of those subscribers will be inside of Vertx and not in the application logic layer.

Please consider this...

Thank you.

[Asher Tarnopolski]

oren,
what about implementing this by pushing a trigger message to your client that will initiate its disconnection? since you have to distinguish between your clients and therefore hold their unique ids anyway, this can solve your problem.

[Nick Scavelli]

I agree with Jordan, seems a little opinionated which the event bus is not.

If it's a common problem maybe there's something you can build on top of vertx to handle your scenario more easily and maybe share with the community ? That way it's not convoluted into a vertx core API but also helps reduce application logic.

[Oren Shvalb]

Asher,

It's mostly done in order to protect the server (not sending information to someone who not supposed to get it), hence I cannot rely on the client to do it for the server.

[TY]

Hi Peter

Did you get your answers or find a solutino in 3.x?   I am currently using 2.x and will be porting to 3.x 

Thanks

TY

On Tuesday, September 23, 2014 at 2:49:54 AM UTC-4, Lenders wrote:

Hi Tim,

Now we've got rid of modules, is it still possible to dynamically deploy verticles at runtime? this was one of the main drivers with us moving forward with vertx.

If this is not possible in the core vertx I'd like to try and contribute something that would enable this but at the moment I wouldn't know where to start; has vertx still got classloader separation etc?

Peter

Disclaimer: This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited.