Linked by Thom Holwerda on Fri 14th Sep 2012 02:30 UTC, submitted by MOS6510
Java "As a typical Java developer I never monitored the memory usage of my application apart from following typical best practices like closing the connections, streams etc. Recently we were struck with few issues in our JBoss servers that I had to dig in to the memory management."
Thread beginning with comment 535093
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[3]: Memory management
by WorknMan on Fri 14th Sep 2012 18:06 UTC in reply to "RE[2]: Memory management"
WorknMan
Member since:
2005-11-13

I will go for new architects.


I figured people would say that, because either on the server or desktop, no matter how shitty Java apps run (which seems to be most of the time), it never appears to be Java's fault.

Reply Parent Score: 0

RE[4]: Memory management
by snowbender on Sun 16th Sep 2012 12:10 in reply to "RE[3]: Memory management"
snowbender Member since:
2006-05-04

"I will go for new architects.


I figured people would say that, because either on the server or desktop, no matter how shitty Java apps run (which seems to be most of the time), it never appears to be Java's fault.
"

The Permgen space is a part of the Java memory that is used for storing definitions of classes. Now, when working with Java application servers (e.g. JBoss) each web application that is running on the server uses its own classloader(s). The class loader is used to load the classes that are used inside the web application. The classloader itself is stored in the permgen space together with all the class definitions it loads.

One issue here is that the more web applications run on your application server, the more permgen space you will need. This is a simple fact and the default space reserved for permgen space is not really enough for an application server with lots of applications on it.

The other issue is that when a web application is unloaded, also the class loader that was connected to it should be freed. This is actually the responsibility of the container, that is the application server itself. The problem is that some application servers do not correctly release those class loaders and that can also lead to the problems you mention.

Is that the architects fault? Nope, not really. On the other hand, as an architect, you should know those things and take them into account when building systems. As an architect, you should really know how classloaders work and how they are linked together.

Reply Parent Score: 2

RE[5]: Memory management
by WorknMan on Mon 17th Sep 2012 01:30 in reply to "RE[4]: Memory management"
WorknMan Member since:
2005-11-13

Is that the architects fault? Nope, not really. On the other hand, as an architect, you should know those things and take them into account when building systems. As an architect, you should really know how classloaders work and how they are linked together.


The problem is that the people that built this stuff have long since left the company, so the current guys are just doing damage control, I guess. Either way, it looks like shit's still going to crash, and I (along with those on my team who are unfortunate enough to get stuck with the pager) will continue to be woken up in the middle of the night. As long as that happens, I will continue to hate Java, whether it is justified or not ;)

Reply Parent Score: 1