Re: Production deploy options - standalone jvm vs war multi-homed jetty

[Henryk Konsek <he...@gmail.com>]

Hi Chris,

>    1. Who here has experience and advice with each of the above three
>    solutions?

Putting many WARs into the same Tomcat tends to leak class loaders
during hot redeploys (leading to memory leaks sooner or later). I
would rather recommend deploying standalone jars instead. The really
cool option is Spring Boot fat war. This is regular war file that can
be executed using "java -jar" or deployed into the servlet container.
So you can start with standalone wars (executed via java -jar) and in
case of devOps issues, migrate to Tomcat/FildFly-hosted WARs without
any problems. Fat wars are my favorite unit of deployment due to its
flexibility.

>    2. The threading model is what concerns me most with running jetty vs
>    standalone.  With PollingConsumes Threads are being created to manage each
>    consume, does the thread model differ between standalone vs running inside
>    jetty.

Well, you end up with a HTTP connection pool anyway, no matter where
you deploy to. :) The really nice option to consider is fat war [1]
with Netty HTTP [2] component. It is fast, scales like hell and is
extremely easy to set up.

>    3. New rest functionality.  Since I am running inside of jetty, do we
>    need to use the netty component, or can we leverage the containers servlet
>    functionality?

You can do both. However I would recommend to base your REST API on
the embedded Netty HTTP instead [2]. You got extra performance for
free. Camel REST works really well with Netty.

>    4. I have also had some trouble with shading jars in the past, any pros
>    or cons with this that can be shared?

You mentioned that you're looking at Spring Boot. If so, then use
Spring Boot Maven plugin to perform the shading for you. Works like a
charm.

> I am really not interested in the difference between tomcat, jetty, or
> jvm.
> Am I just getting the functionality of the container, or does
> it the route actually run differently.

Route will work the same until you configure it to take advantage of
the servlet container you deploy to. However I personally prefer to
use embedded HTTP connectors. They are much easier to deploy and test
for end-to-end scenarios.

Cheers.

[1] http://spring.io/blog/2014/03/07/deploying-spring-boot-applications#what-about-the-java-ee-application-server
[2] http://camel.apache.org/netty-http.html

-- 
Henryk Konsek
http://henryk-konsek.blogspot.com