Vert.x and Servlet integration

[ad...@cs.miami.edu]

We have a web app developed with Tomcat. We would like to add some vert.x type features to the app (real time features, accessing rest services in a non blocking way, etc).

I am trying to think of a good way to take an existing servlet deployment and  integrate it, and continue its development using vert.x

Here is what I have come up with:

1) run tomcat in a separate JVM than vert.x , and use vertx as a proxy to tomcat for the elements that should stay in tomcat. Then just build out any applicable new features in vert.x.

2) Somehow run them both in the same JVM. This could be implemented as an embedded tomcat (but this seems like it would require tomcat to listen on another port, which might be a problem).

3) Create a servlet worker vertice that handles the servelt api as a worker verticle so that vert.x can directly run a servlet. This option sounds cool, but is probably way more work than it is worth (unless someone has already done this)

So, option #1 seems to be the best option. Any other ideas.

-Adam

[Julien Viet]

for 2/ : you can embed Vert.x very easily in any runtime

--
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.
Visit this group at https://groups.google.com/group/vertx.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/c7b7be2c-56ea-4473-8d1c-f2e1cc31d2a0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Ravi Luthra]

If you are ultimately interested in supporting SockJS and the eventbus bridge, I would "front" Tomcat with Vert.x. Actually I would probably front Tomcat AND Vertx with Nginx. If this presents issues "authentication wise" then I would figure out how Vert.x can "call" Tomcat directly with the browser's request and pull back user data (Like username, roles, etc.. but not password).. For example a new Servlet that just returns user information of the connected user. As long as that servlet responds successfully to Vert.x, then it can assume the user is authenticated.

[ad...@cs.miami.edu]

Yes, my current concept is to front tomcat http requests with a vertx proxy.   Requests that are to be servered by tomcat will be proxy passed on to vertx.  This will allow me to build "around" the permiter of an existing tomcat app with out any major issues.

I am not initially seeing too many benefits of putting nginx infront of vertx, they are both ansync non blocking servers, so it would seem redundant, what are the benefits?

Thanks,

-Adam

[Alexander Lehmann]

Usually a front end accelerator proxy will not be a java program (or ruby or python program for that matter) since it is not good to run the app server as root to be able to bind to port 80 and 443.

There are a few other setups possible like setting the local firewall to map port 80 to port 8080.

[Tim Fox]

On 01/04/16 11:34, Alexander Lehmann wrote:

Usually a front end accelerator proxy will not be a java program (or ruby or python program for that matter) since it is not good to run the app server as root to be able to bind to port 80 and 443.

What do you mean by app server? I'm not sure I follow the logic here.

--

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.
Visit this group at https://groups.google.com/group/vertx.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/b4e10251-682d-4407-b31e-fa8c0832611c%40googlegroups.com.

[Alexander Lehmann]

Any Java, Nodejs, Ruby or Python server is usually not trustworthy enough to run it as root.

[Tim Fox]

I don't see why a C program is inherently more secure than a Java program or a program written in any other language.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/5371970f-b5d7-416d-926f-f733d0520e19%40googlegroups.com.

[Alexander Lehmann]

That is true, however a front end web server usually will have much less features enabled and is a more "standard" piece of software. Plus in the case of Apache and nginx, the server can relinquish the root privileges for the process after binding the port, which is difficult to do in a java program.

[Tim Fox]

On 01/04/16 12:14, Alexander Lehmann wrote:

That is true, however a front end web server usually will have much less features enabled and is a more "standard" piece of software.

If you're talking about putting a Java "app-server" (e.g. JBoss AS etc) on the front I would agree with you, but we're talking here about a simple Vert.x verticle which probably has fewer features than your average "standard" web server.

I actually think Vert.x could be an excellent choice for writing a software load-balancer / proxy to rival nginx. (This is actually something I've wanted to do for a long time).

Of course, you would only want to put a simple load balancer at the front end to limit the attack area, and load balance requests to your farm of Vert.x instances at the back which can run on non 80 ports and private IPs.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/916a738b-0b16-4010-8630-d71db99e5622%40googlegroups.com.

[ad...@cs.miami.edu]

Regarding security of a java server, when I run tomcat or vertex standalone, I run them from an unprivileged user and use iptables to forwrd from 80 to 8080 (or whatever).  I don't think one can get more secure than that, and java (in general) has less attack vectors than other executables.

I think vert.x could be great as an http proxy and load balancer to a farm of existing tomcat apps.  And by putting vertx in front, we can then start adding new features that tomcat is not as good at handling (ie realtime web features, etc), all being serviced from the same domain.  I do not know if there is an existing reverse proxy setup for vert.x, but I can't imagine that it would take more than a morning and a few cups of coffee to program up (at least a simple version).

I would love to see how vert.x compares to nginx in the domain.

Best,

-Adam

[Alexander Lehmann]

I apologize, that really makes sense, however I would go with the iptables redirect nonetheless.

[ad...@cs.miami.edu]

Alexander,

No apology necessary.  My understanding is that this is a "disucssion group", we are not experts, but users who freely discuss ideas and thoughts.

Your instinct about Nginx is probably accurate in many situations.  However, my guess that a vert.x proxy verticle would be able to compete well with Nginx for this use case. 

Best,

-Adam

[Alexander Lehmann]

Proxy support might make sense as an addition to vertx-web, similar to e.g. express.js

[Klausen Schaefersinho]

hi,

There is another thing co keep in mind. Due to some bug vertx is quite slow with ssl, so it might make anyhow sense to use Nginx as a proxy...

[ad...@cs.miami.edu]

Hi,

If vert.x is in fact slow with ssl, that would make a poor proxy.  Can you please provide more information as to how and why vert.x is slow with ssl.  When you say slow, what to you mean?  Do you mean it is slow due the ssl engine it uses (java based or openssl based, etc)?

-Adam

[Daniel Lindberg]

You can read about it in this post: https://groups.google.com/forum/m/#!searchin/vertx/Ssl$20performance/vertx/On0WgBPzOPQ

[Julien Viet]

which bugs are you referring to ?

besides we are going to support OpenSSL is coming in Vert.x 3.3 (the PR is ready)

> On Apr 3, 2016, at 11:18 PM, Klausen Schaefersinho <klaus.s...@gmail.com> wrote:
>
> hi,
>
> There is another thing co keep in mind. Due to some bug vertx is quite slow with ssl, so it might make anyhow sense to use Nginx as a proxy...
>

> --
> 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.
> Visit this group at https://groups.google.com/group/vertx.

> To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/53d6da48-8004-4e5f-906e-321f81a90d5f%40googlegroups.com.

[Klausen Schaefersinho]

https://github.com/vert-x3/issues/issues/62

[ad...@cs.miami.edu]

Thanks everyone for the recent replies about the possibility of using vertx as proxy, along with ssl features.

I took a look at some of the ssl performance threads, and it is not clear to me that there is really a "bug" in vert.x.  Instead, it seems that vert.x is currently missing a desired feature, namely openssl support. I am very happy to hear that openssl is ready to roll in an upcoming release of vert.x (awesome!).

I did some quick (non professional) tests with vert.x's java based ssl, and I did not find the results to be too bad.  I pitted tomcat nio's java ssl against vert.x's java ssl.  I tried to make it as much of apples to apples as I could, considering the different platforms.

 Vert.x took a slight lead over tomcat nio when serving up an in memory character string of about .5 MB.   What this tells me that there does not seem to be a performance bug in Vert.x's ssl.  Instead, jdk's ssl is just slower than we want... and vert.x is doing what it can despite this.

It would be ideal if there was a pure jvm alternative to the jdk's ssl implementation (perhaps there is).  There is something good (in my opinion) about keeping it all on the jvm.







On Monday, April 4, 2016 at 3:05:57 PM UTC-4, Klausen Schaefersinho wrote:

https://github.com/vert-x3/issues/issues/62

[Julien Viet]

OpenSSL support will be in 3.3

--
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.
Visit this group at https://groups.google.com/group/vertx.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/5485ddad-6ea5-4d6a-a46e-331c72e6932a%40googlegroups.com.