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

[Christopher Love <ch...@cnmconsulting.net>]

Hi all

First of this is an awesome project, I am always touting how I can write
four lines of code, and do SO much.

Background:

We are currently running in production tomcat with separate wars for
different camel projects.  One of the projects is quickly becoming a
monster where we will need to shard routes to different servers.  A this
point this is far out on the development schedule.

Because of dev ops technical challenges with running the different wars
inside of the container / jvm we are looking at running each camel route
insides it's own jvm.  We have three different options that we are looking
at:

   1. multi-homing tomcat - we are seeing more memory being used by tomcat
   than the other solutions that we are assessing.  Tomcat provides a lot of
   features that we are not using.
   2. multi-homing jetty - keeping our war standard, this is a more light
   weight container solution.  We could again run one instance of jetty, with
   multiple wars, but we want to run separate jvms.
   3. standalone jars - we would need to change to assembly packaging, but
   this is simpler setup than multi-homing jetty.

Open Questions:

   1. Who here has experience and advice with each of the above three
   solutions?
   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.
   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?
   4. I have also had some trouble with shading jars in the past, any pros
   or cons with this that can be shared?

I am really not interested in the difference between tomcat, jetty, or
jvm.  I am interested on how camel functions differently inside of a jvm vs
a container.  Am I just getting the functionality of the container, or does
it the route actually run differently.

Thanks

Chris

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