I am just starting to look into web hosting services but I am curious how services that offer JVMs for back-end apps operate. These are pretty newbie questions. I have experience with back-end applications on a dedicated server from my previous job (where most of these questions were not an issue).

How does a shared JVM work? How does that run more than one app simultaneously and how does one app get updated w/o shutting down the whole JVM?

Java tends to use lots of memory - from people's experience how well do these dedicated JVMs with only 50M of RAM work (for small apps)?

How much control does that client usually have over the JVM options (classpath, logging, etc etc)?

How does app deployment usually work? Can the client FTP the app and then restart the JVM themselves?

thx

My suugestion is that you seek answer else where. Most people in this forum are not extremely familar with Java.

Some of your answer can be found in Java online forum/community. I will say that to find the answers, you need to know what Servlet container you are using, then search their support forum for these question.

As for shared JVM. I have heard that mycgiserver.com has proprietary technology that allow them to run shared JVM(which has better performence but with the issue of shared classpath/system resources...). But they don't seems to be licensing that technology right now.

Java does use a lot of memory, but if you have enough memory, it is very fast and extremely scalable. 50 MB server, however, I don't think will cut it. (50MB for the JVM is good, for the whole server is not enough)

There aren't too many hosts that offer full-fladge java web application support. (They only offer servlet/jsp). You have to find out what container the host is using, than ask the host or seek help in appropriate support forum.

Peter

Hmm... The only time I think you would run the Java VM as a service is if you we're providing JSP/Servlet/EJB hosting.

Other than that download Java Virtual Macine from http://java.sun.com, compile it, and then give your users the information about its location.

Users just telnet/ssh into the system

and at bash type something similar to this:

[mattfreeman@panther www]$ /usr/jdk1.3.1/java/bin/java -cp "." javaapp.main

This starts a new instance of the JVM in the user's security context and run the application, when the application finishes it terminates.

If the app runs continuously then the user would enter:
[mattfreeman@panther www]$ /usr/jdk1.3.1/java/bin/java -cp "." javaapp.main &

The '&' puts the application into the background and continue to run when the telnet sessions is closed I believe (will have to confirm).

Probably best asking on a Java message board for more accurate
advice. :)

Matt is right if you're not trying to offer servlets/jsp. Though java on a server without servlets/jsp support is kind of like installing perl on a web server but not allowing cgi.

If you're talking about offering servlets/jsp on a shared server that's another story. I've only be a user on a shared server that supported servlets but now I'm running them on my own dedicated machine. Basically you want to install tomcat or some other servlet runner and set it to automatically reload new classes. Then you setup the directory structure and create a symbolic link to say a servlets directory under the user's home directory. The users get new code installed by dropping the class files into that directory. No need to restart tomcat since you have it set to reload the classes.

Users don't get to mess with the classpath. You can install some commonly used things there for them (MySQL drivers for example) or they can just go ahead and install them under their servlets directory directly. If they have a .jar file they'll just need to unjar it out into the individual files and it'll work just fine.

The shared JVM seems stable enough. About the only problem I experienced was you can have name space collisions. The biggest problem was when one of the other users installed the (non-working) beta version of the MySQL drivers and broken the drivers for everyone on the machine. I solved that by simply renaming the class and recompiling it.