• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Private JVM & misc

 
Ranch Hand
Posts: 782
Python Chrome Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
(1) Some of the j2ee hosting vendors advertise the fact that they're able to offer "private JVMs" ? What does that phrase mean ?
(2) I know that it's possible to have multiple classloaders in one JVM. Why is that a problem when you're clustering J2EE appservers ?
Thanks
Pho
 
Rancher
Posts: 13459
Android Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
J2EE application servers tend to use ClassLoaders to separate code between applications.
That is, a single servlet container can be running multiple web applications under multiple contexts, but since they are running under different ClassLoaders they cannot 'see' each other and are unable to effect each other. In terms of separation of code and security, this is a very good thing.
The other option is to have each web app running in its own private JVM but still allow the server to manage the requests. The ClassLoader solution is very clever, but is not always implemented well. For example, it is not always possible to stop and start individual web-applications, and you can't add and delete them without bouncing the server.
Without being an expert, we have found that the JVM solution can be used to provide fake fixes for some of the problems above.
Other issues it introduces is the fact that common code can no longer be shared and must be loaded and maintain its own state in each JVM, it is more complicated, and the servers can no longer optimise remote-calls-to-local-objects. (that is if the EJB and Servlet containers are in the same JVM, the server can maintain a local reference rather than requiring remote communication)
I hope none of this is misleading...
Dave
 
Pho Tek
Ranch Hand
Posts: 782
Python Chrome Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
David,


For example, it is not always possible to stop and start individual web-applications, and you can't add and delete them without bouncing the server.


Aah! I get it. This is the classic class reloading problem on Tomcat and other servlet containers.

..optimise remote-calls-to-local-objects.


My conclusion from your comment is that in order to communicate between multiple JVMs, all method calls become remote calls. Is "remote" referring to RMI ?
Another 2 related question: if we have multiple classloaders (i.e. multiple webapp contexts) running on one JVM; would that be more efficient in terms of memory usage than a solution with multiple JVMs -- assuming some finite amount of memory on the server. Is there an upper limit to accessible memory for the JVM
What identifies a JVM instance ? If I have JVM1 and JVM2 running on a single machine, how do I differentiate between them ?
Thanks
Pho
 
David O'Meara
Rancher
Posts: 13459
Android Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

My conclusion from your comment is that in order to communicate between multiple JVMs, all method calls become remote calls. Is "remote" referring to RMI ?


I'm not sure about the machanics of the communication between a server and webapps in their own JVM. It could be via RMI or could be as simlpe as passing on the HTTP request. As far as I see it, there would have to be some extra communication overhead though.

if we have multiple classloaders (i.e. multiple webapp contexts) running on one JVM; would that be more efficient in terms of memory usage than a solution with multiple JVMs -- assuming some finite amount of memory on the server.


I tend to think it would, since it is similar to the 'process versus thread' argument. In a single JVM you have applications running as threads under a single process. The 'process footprint' only counts once. In addition, you only have to load the classes of 'library' style code like log4j, xml libraries etc once and they can be shared safely by all applications in the JVM. If you have multiple JVMs they each have to load these classes.
You may also find that Singleton classes no longer behave like Singletons since each JVM will probably have a copy loaded.

Is there an upper limit to accessible memory for the JVM


Each JVM would have to be defined a starting and maximum amount of memory it was allowed. (ie the 'java -X' options) Therefore yes, there would be a defined limit, since each JVM would have a pre-defined memory footprint.

What identifies a JVM instance ? If I have JVM1 and JVM2 running on a single machine, how do I differentiate between them ?


Dunno. I've seen people bring up similar issues, but I've never had to worry about it...
Dave
reply
    Bookmark Topic Watch Topic
  • New Topic