PermGen is the area of memory that holds class files. Anytime you have lots
of class files you have to increase this.
Java loads classes on demand in most cases, EJBs don't magically give you
this ability. A web container such as Tomcat or Glassfish may load the
servlet and web service endpoint classes eager but that about it.
If Java (heap) memory usage keeps rising over time then that means you have
a memory leak. This is typically caused by object being created and not
releasing them. Sometime app developers go crazy with the amount of object
placed in the HttpSessions so memory usage seems to keep climbing until you
hit a plateau when the sessions finally start expiring as fast as new
sessions are being created.
Some Java developers can be sloppy with memory usage, it's the bad aspect of
Java's portability. Many Java developers don't think in terms of hardware
resources. Of courses you can also compare the hourly cost of a developer
optimizing memory usage with the price of RAM. One gig is worth about $10
dollars last I looked. Throwing more RAM (and adjusting the JVM memory
tunables) is a common solution, at least until garbage collection become the
bottleneck.
Reloading .class files in a running application is typically not possible
with normal JVMs. You can reload .jsp files though.
You shouldn't be restarting either GlassFish or Tomcat when you have
application changes. You should be just reloading the WAR file. GlassFish
has a couple of easy ways to do this. With Tomcat you need to look at
enabling the manager application so you can enable/disable/reload the web
applications (WARs).
EJB's would allow you to break the application up into smaller modules that
could be reloaded independently but it would require the use of Remote EJBs
which would add a bunch of overhead.
For apps that need 100% uptime but need to be brought down for bug fixes you
need multiple servers. A possible solution would be to have a load
balancer/router in-between your customers and your servers. All traffic
would initial be directed to serverA. When an updated version becomes
available you would install it to serverB. You tell the router to send all
new clients to serverB. Eventually all the customers using serverA log off
at which point you can restart serverA with the updated app. I think the
expensive applications servers might be able to do dynamic migration like
this with a single box, not sure if GlassFish has something built-in or not.
None of the dynamic migration or cluster features are covered by the specs
so it all varies by vendor.
The big things that EJBs do are:
* Handles transactions so developers don't have to write transaction code
* Handles security so developers don't have to write security code
* Handles threading issues by allowing applications to be multi-threaded
without requiring developers to have to worry about thread synchronization
* Easy to create messaging consumers
So in summary, EJBs are great things but I don't think they will fix your
problems. GlassFish (also great) probably won't fix your problem but it
does have much better management interfaces than Tomcat so I'd still suggest
trying it out.
-Matthieu Chase Heimer
On Tue, Jan 26, 2010 at 7:20 AM, Blake McBride <blake_at_mcbride.name> wrote:
> Greetings,
>
> I have a rather large web service app written in Java and (currently)
> running under tomcat. I am having a number of problems that I will describe
> below. One of my associates suggested that EJB's & Glassfish could solve my
> problems. Before I spend an inordinate amount of time, I though I would ask
> the experts. If you could answer my questions, I would greatly appreciate
> it.
>
> THE PROBLEM
>
> 1. The app takes 1 GB of RAM and 256 MB of Java PermGen space to boot
> (tomcat), and it grows daily. Even though only a very small sub-set of the
> Web Services are ever used at the same time, and often its the same small
> set of them are used at all, the system seems to load all of them at boot
> time ( or at least allocate the max memory needed). This is cumbersome and
> unwieldy, and I think the problem is going to hit some practical limit in
> the not too distant future.
>
> 2. The second problem is that the smallest bug in any single module
> basically causes us to re-deply the entire application (after fixing the
> bug), and rebooting tomcat. I'd like to be able to fix the bad .class file
> and just copy it over to the server and have the server just start using the
> new file rather than rebooting the entire server.
>
> 3. Adding web services or making significant changes to existing web
> services is a major event i.e. a lot of files change and we have to reboot
> tomcat. I'd like to be able to install new web services or make significant
> changes to existing web services without rebooting tomcat (or glassfish).
>
> SOLUTION QUESTIONS
>
> I don't currently use EJB's. My associate suggested that EJB's under
> Glassfish might solve my problems. I know with EJB's I can spread my web
> services over several machines. I do not want to do that. I want all the
> services to run on one machine (and probably one instance of glassfish).
>
> 1. With respect to the RAM & PermGen space, I am hoping Glassfish / EJB's
> will only load the EJB's as needed AND will be able to completely unload
> them when not in use. So the RAM & PermGen requirements would only relate
> to what is current;y running and unrelated to the number of EJB's available
> or what has run previously.
>
> 2. I am hoping EJB's / Glassfish will allow me to install new or
> arbitrarily modified web services or other EJB's while the system remains
> running.
>
> I really appreciate your input.
>
> Thanks.
>
> Blake McBride
>
>