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

Reply via email to