[ 
https://issues.apache.org/jira/browse/AXIS2-5696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16947440#comment-16947440
 ] 

Randi commented on AXIS2-5696:
------------------------------

The project I am working on have experienced the same issue.

Turns out that this changeset: 
https://github.com/apache/axis2-java/commit/4e54e5bca6cac6134032f233a5de75fb3d7b531a
 getting rid of the backport version of java.util.concurrent also commented out 
the call to ThreadPoolExecutor.allowCoreThreadTimeOut(true) since it is only 
supported from JDK 1.6. It even has a "FIXME" comment on it.

What this means for ThreadPoolExecutor is that unless shutdown is called they 
will leak threads since the number of core threads is > 0.

ThreadPoolExecutor has an inherent leak in that Threads in the executor links 
back to the ThreadPoolExecutor itself creating a cyclic reference. Threads are 
also referred by the ThreadGroup to which they are attached. This is by default 
the same ThreadGroup as all other threads, which keeps the Threads from being 
garbage collected.

Allowing core threads to timeout solves this issue.

What we ended up doing was a hack with some casting and calling 
allowCoreThreadTimeout from our application code. Not pretty, but does the 
trick.

> Axis 2 threads are not closing properly
> ---------------------------------------
>
>                 Key: AXIS2-5696
>                 URL: https://issues.apache.org/jira/browse/AXIS2-5696
>             Project: Axis2
>          Issue Type: Bug
>    Affects Versions: 1.6.2
>         Environment: Operating system: LINUX 
> (uname -r 
> 2.6.32-431.29.2.el6.x86_64)
>            Reporter: Rajan Arora
>            Priority: Major
>         Attachments: Axis2 libraries.7z
>
>
> Hi team,
> We have seen a very large amount of axis 2 threads leaks in our environments. 
> We are using a 
> WebSphere Application Server Network Deployment  8.0.0 on Linux operating 
> system
> We are having application deployed on this Application server which are using 
> Axis 2 library 1.6.2 version. I am attaching the library for your reference. 
> We are seeing AXIS2 Threads are not closing at all and they are consuming 
> memory and finally after few days the application fails due to exhaustion of 
> Native Memory. Most of the Native Memory is being consumed by Axis 2 threads. 
> We did raised this issue with IBM as we are using IBM application server to 
> host our applications. After a detailed analysis of couple of months IBM have 
> confirmed that its not an issue with their product of SDK. They believe its 
> an issue with 
> As per IBM latest comments In our code we are calling the Thread pool 
> shutdown however the threads are not getting terminated at all. Please refer 
> the below comments. 
> Please do let me know if any further details are required.
> ==========================================================
> The trace shows ThreadPool objects are created by this stack:            
>                                                                          
> org.apache.axis2.util.threadpool.ThreadPool.<init> (ThreadPool.java:53)  
> org.apache.axis2.context.ConfigurationContext.getThreadPool              
> (ConfigurationContext.java:648)                                          
> org.apache.axis2.description.OutInAxisOperationClient.executeImpl        
> (OutInAxisOperation.java:232)                                            
> org.apache.axis2.client.OperationClient.execute                          
> (OperationClient.java:165)                                               
> au.com.amp.www.afs.idam.eventnotificationservice_v1.EventNotificationSer
> viceStub.startsendEvent                                                  
> (EventNotificationServiceStub.java:315)                                  
> au.com.amp.isam.eai.util.PredatorClient.sendEvent                        
> (PredatorClient.java:158)                                                
> au.com.amp.isam.eai.util.PredatorClient$$FastClassByCGLIB$$aad7be26.invo
> ke                                                                       
> (<generated>)                                                            
> net.sf.cglib.proxy.MethodProxy.invoke (MethodProxy.java:204)             
> org.springframework.aop.framework.Cglib2AopProxy$CglibMethodInvocation.i
> nvokeJoinpoint                                                           
> (Cglib2AopProxy.java:689)                                                
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed     
> (ReflectiveMethodInvocation.java:150)                                    
> org.springframework.aop.interceptor.AsyncExecutionInterceptor$1.call     
> (AsyncExecutionInterceptor.java:83)                                      
> java.util.concurrent.FutureTask$Sync.innerRun (FutureTask.java:314)      
> java.util.concurrent.FutureTask.run (FutureTask.java:149)                
> java.lang.Thread.run (Thread.java:773)                                   
> /util/concurrent/ThreadPoolExecutor.<init>(IIJLjava/util/concurrent/Time
> Unit;Ljava/util/concurrent/BlockingQueue;Ljava/util/concurrent/ThreadFac
> tory;)V                                                                  
> Bytecode method, This = 17c764838                                        
>                                                                          
> This thread then creates a ThreadPoolExecutor and then a Thread.         
> The ThreadPool shutdown methods were not called.                         
>                                                                          
> ServiceClient.cleanup() is being called by the finalizer for             
> ServiceClient (and also by org.apache.axis2.client.Stub.cleanup() which  
> is called by the finalizer for Stub, which I assume is a superclass of   
> au.com.amp.www.afs.idam.eventnotificationservice_v1.EventNotificationSer
> viceStub;                                                                
> see below). However, this does not seem to lead to the associated        
> ThreadPool being shut down.                                              
>                                                                          
> The dump shows there are:                                                
> 2 org/apache/axis2/client/ServiceClient                                  
> 336 java/lang/Thread                                                     
> 1 org/apache/axis2/util/threadpool/ThreadPool                            
> 294 org/apache/axis2/util/threadpool/ThreadPool$DefaultThreadFactory     
> 301 java.util.concurrent.ThreadPoolExecutor                              
> 294 java/util/concurrent/ThreadPoolExecutor$Worker                       
>                                                                          
> 1 of the ServiceClient objects references the 1 ThreadPool. The          
> ServiceClient is kept alive by                                           
> au.com.amp.www.afs.idam.eventnotificationservice_v1.EventNotificationSer
> viceStub                                                                 
> @ 0x17f560dd8, which is waiting to be finalized.                         
>                                                                          
> SUMMARY:                                                                 
> * Identified the code which creates the ThreadPool objects (and the      
> "Axis2 Task" threads)                                                    
> * Noted that ServiceClient.cleanup() is being called, but doesn't lead   
> to ThreadPools being shut down                                          
> L3 Java J9Core has confirmed same issue from latest set of data and does not 
> involve or point to JDK/SDK code.  Issue should be
> further investigated by owner of Axis2 to help explain why threadpools are 
> not being shutdown properly.                                      
> -------------------------------------------------------------------------------------------



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to