Yep, An excellent test which we could not have done in our own
environment. Since you have the setup already, here's a little
"request" (:))from us to pinpoint the problem.
Eran has a valid point about the heap size. You should definitely try it and see. But I've a hunch that this could be a problem with Axis2. So would you be able to run a profiler and check which object instances produce this problem ? I guess you can use one of the open source profilers like ejp (http://ejp.sourceforge.net/) or Jprofiler has an evaluation version that should work for this case.
Excellent test and amazing results !! I wish if I could be there too.
I admit that we haven't done good profiling on Axis2. For some reason it
is getting postponed. But its not a good excuse.
Since you have some good configuration, can you help us to improve ? We
all really appreciate if you can help in that. If you have time, please
find the bottle necks and post them here. Lets discuss and fix them.
I know for sure there is a problem in life cycles of context hierarchy.
Another small issue. Did you try increasing the heap memory of Tomcat.
However much memory you have, if the heap size is small, you are not
gaining (I think) from your huge memory.
>Sorry to bother you guys again, but i'm having another problem! I dont' know
>what it's happening but my webservice in Java through Axis2 (with Tomcat5.5) it
>can only process about 4880 requests in less that one minute, then it stops and
>starts to throw java.lang.OutOfMemoryError Exceptions!
>Note that this webservice is almost identical to another one that was running
>through Axis(1.3) that didn't give me any problem in the exactly same
>The Server(Tomcat) and WebService are running in a Windows Server 2003 in a AMD
>Dual Opteron (2x2GHZ) with 2GB DDR Dual Channel (actually it's 4GB but we
>removed 2GB for these tests).
>I'm running a Benchmark Test in a cluster! The Server is receiving requests from
>10 machines, each of them has 10 connections sending requests in burst mode
>(send-receive-send...). It's a stress test with the objective of crashing the
>server...but i hoped that would last longer than 1 minute (!?).
>If you have a solution it will be great, but knowing the reason (i presume it's
>not due to my java service application...) for this to happen will also be well