[
https://issues.apache.org/jira/browse/AXIS2-4742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Prakash C Rao updated AXIS2-4742:
---------------------------------
Attachment: gclog_profilereport_client_service_code.zip
I'm attaching gc log, profile report, client and service code all bundled in
one zip file. .
> Axis2 1.5.1 memory issues when invoked stub client in multiple threads
> ----------------------------------------------------------------------
>
> Key: AXIS2-4742
> URL: https://issues.apache.org/jira/browse/AXIS2-4742
> Project: Axis2
> Issue Type: Bug
> Components: adb
> Affects Versions: 1.5.1
> Environment: Windows XP professional, service hosted in tomcat 5.0.28
> & Tomcat 6.0.26, JRE version 1.5.0_14, 32 bit OS, Total Physical Memory - 4
> GB, Total RAM - 1.58 GB,Total VM - 2.00 GB,Available VM - 1.96 GB,Processor -
> x86 family 6 Model Intel 2494 Mhz
> Reporter: Prakash C Rao
> Priority: Blocker
> Fix For: 1.6
>
> Attachments: gclog_profilereport_client_service_code.zip
>
>
> We are using Axis 1.4 library for our current production system and we are
> hitting out of memory due to de-serialization bug in Axis 1.4.
> https://issues.apache.org/jira/browse/AXIS-2698
> Later we found Apache has stopped working on Axis1 generation (1.4 is the
> last version) and has moved to Axis2 generation. I did lot of reading and
> found good things (especially on memory footprint) about Axis2 and we made a
> decision to move to Axis2 1.5.1. Before using this for our product, we did a
> small POC on Axis2 1.5.1 confirm what is being claimed (as far as memory foot
> print is concerned) is really true.
> In my POC I wrote a sample application and I invoked 4 simple service APIs in
> multiple threads. I see memory growing drastically up to 900MB - 1GB and lot
> of GC happening. And even after full GC the memory stays up for some
> duration. I read lot of articles on internet about Axis2 and came to know
> that there were memory leak issues in Axis2 1.4 which was fixed in Axis2 1.5
> but I still see memory issues in Axis2 1.5.1. I also did POC with our product
> code using Axis2 1.5.1 and I see same results (high memory usage) when I
> invoke stub using multiple threads.
> From the articles I came to know that stub is not thread safe but I've made
> sure thread safety for stub creation. I'm creating only one configuration
> context object and I'm creating new stub for each invocation which uses that
> configuration context. After the invocation, I'm cleaning up the stub &
> transport to ensure all cleanups are being done properly. I'm also caching
> http client for better performance and setting auto release flags for proper
> cleanup. I've followed all best practices that I Amila has suggested (thanks
> very much Amila) in his various blogs. I also debugged Axis2 1.5.1 code to
> see usage of various flags that I've set in the code. In spite of all this I
> see lot of memory usage. In fact I see better results in Axis 1.4 as far as
> memory is concerned.
> I'm attaching the source code for client (rl.txt -> rename to rl.bat starts
> the client in various threads), service, GC log & profiling report. From the
> profiling I see huge references to the below objects that's being mentioned
> in http://www.5341.com/list/56/222882.html
> java.util.concurrent.ConcurrentHashMap$Segment
> java.util.concurrent.locks.ReentrantLock$NonfairSync
> java.util.concurrent.ConcurrentHashMap$HashEntry[]
> One of Amila's blog talks about caching stub object but I'm afraid of socket
> timeout if I use the same stub for longer period of time (hence I'm creating
> new stub each invocation and cleaning up after call is done).
> Could you please help me out in this regard?
> Btw, I should really thank Amila for most of his blogs on Axis2 (2 of them
> I've listed below). It was really helpful for me.
> http://www.5341.com/list/56/222882.html
> http://amilachinthaka.blogspot.com/
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
