Roland Benedek

Greenhorn
+ Follow
since Jun 06, 2008
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Roland Benedek

Because there are two types of ordering for interceptors, first there is the declaration:
1. Default interceptors(those declared in the orm.xml)
2. Class interceptors
3. Method interceptors

Per declaration type the order is:
1. Super class
2. Own class

Hope this helps
Hello,

I think:

Will work just fine.

On second thought, this doesnt work its not getSize();

[ September 09, 2008: Message edited by: Anton Gerdessen ]
My guess would be because you use <%= %>

Which can print variables and all the other items are seen simple text and surrounded by quotes?
Maybe if the server or container the application is in, receives a shutdown command.
Or the application itself is undeployed.

I suppose each servlet in the running application will receive a request to shutdown and call destroy().

Could be wrong though.
Thanks for the replies all.

No CMS when there is a lot of ‘young’ generation. Ok point taken.

Dropped the CMS collector all together.

Out of memory due to the maximum number of threads, no cant be it reduced it to 100 and I still get it.

I found a very good whitepaper though:
http://java.sun.com/performance/reference/whitepapers/tuning.html#section4.2.6

This way I decided to try:


-Anton
[ June 09, 2008: Message edited by: Anton Gerdessen ]
15 years ago
Hello,

I recently ran into a problem with a webservice leaking memory badly when its hammered with request.
After some research it seems that the garbage collector cannot keep up?
The webservice itself it a java wrapper*(axis and some custom code) around a pl/sql procedure.
And yes all connection and jdbc objects are closed/freed.

It is my believe that the GC cannot keep up near the end.
I try to create a testcase to reproduce this. I cam up with the following but I cannot understand why I get out of memory errors.


There are hardly any references kept by classes. All objects instanciated should be ready for garbage collection right after they have been created, why does it run out of memory?

In the log I can see the number of instances increase but hardly any finalizers being called near the end.
At the start a fair number of finalizers gets called but this stops.
In terms of memory usage I see the expansion at first and when its getting close to the 64M mark (yes I know this is implicitly set and I can increase this) the finalers stop being called and memory stops being freed.

It was I was afraid the object creation in simpleobject was keeping the object on the method stack so I removed the instantiation to its own method. But I�m not sure if this helps.

I know this program is ridiculous and I�m not even sure if it represent the problem in the webservice but I just cannot understand what is going on. I have like NO references why aren�t all simpleobjects being finalized? Near the end (60secs) I see around 1.000.000 open instances not being gc�d.

I have read:
http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html
But this does very little.
I can increase the programs life to 120 seconds but the processes comes to a near stop from 70-120secs
I used the parameters:

Note that the guide lists �XX(+)CMSIncrementalDutyCycle=10
With an extra (+) this is wrong and not accepted by the JVM

Another thing which I have noticed and which I cannot believe is that when I compile my source as 1.2 instead of 1.4 it crashes even earlier and GC behaviour seems even more out of control, releasing even less objects.

Anyone got a clue what is going on?
[ June 06, 2008: Message edited by: Anton Gerdessen ]
15 years ago