0

For Example:

I am having one primary temp domain

www.product.com

For each client i need to have separate sub domain mapped to same server with same port(80) but with different instance name (different .wars files)

I used apache server as reverse proxy for mapping jetty instances

www.client1.product.com
www.client2.product.com
www.clientn.product.com

As i know if i start jetty instance , each will start at seperate port no's

client1 war will start at port 3001
client2 war  will start at port 3002
client3 war will start at port 3003

Update:

for more understanding of my architecture , if client2 jetty instance running on port 3002 went to down state due to runtime exception or memory leakage or manual restart , all other jetty instances running independently (similar to architecture behind google appengine uses jetty)

if i access

www.client4.product.com , i need to get jetty app running in port 3004

so internally each client wars running under unique jetty instances with separate port no's

**What my question is all clients using same code base but with different database names , so libraries used in all client war files are same.**

1)Are same libraries loaded n times(ie for n jetty instances) on memory?

2)Can jetty have shared lib folder similar to tomcat, if yes need steps.

Sam
  • 685
  • 12
  • 34

1 Answers1

1

Each library is loaded into memory separately. Different JVM processes on the same machine do not share anything with each other as far as what classes are load, memory space used, etc.

matt b
  • 138,234
  • 66
  • 282
  • 345
  • Can u please explain bit in depth, in contrast with QA http://stackoverflow.com/questions/267953/managing-libraries-in-tomcat – Sam Aug 29 '12 at 20:03
  • 1
    You are running four different Jetty processes which do not know about each other. There is no opportunity there to load a .jar just once into memory. In order to do so, you'd have to run one Jetty JVM process with 4 webapps in it, but putting commonly used JARs in a common classloader is typically a pain-in-the-butt for these webapps as it's not worth the dependency headache to save a few hundred KB or a few MB of RAM. – matt b Aug 29 '12 at 20:05