[ 
https://issues.apache.org/jira/browse/AXIS2-5696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Lazarski resolved AXIS2-5696.
------------------------------------
    Resolution: Fixed

Root cause: When the backport java.util.concurrent was removed,       
  ThreadPoolExecutor.allowCoreThreadTimeOut(true) was commented out with
   a // FIXME: This API is only in JDK 1.6 note. Since core pool size is
   5 and core threads never time out, idle "Axis2 Task" threads persist
  indefinitely. Combined with ThreadPoolExecutor's cyclic reference
  (Worker threads reference the executor which references the Workers),
  threads are never garbage collected. Additionally,
  ConfigurationContext.terminate() never shut down the ThreadPool.

  Fix:
  1. Enabled allowCoreThreadTimeOut(true) on the ThreadPoolExecutor —
  idle core threads now terminate after the already-configured 10-second
   keepAlive period. The JDK 1.6 FIXME is long obsolete (minimum is Java
   8+).
  2. Added ThreadPool shutdown in ConfigurationContext.terminate() as
  defense-in-depth, so threads are cleaned up promptly on explicit
  termination rather than waiting for idle timeout.

  This also resolves the duplicate AXIS2-5852.



> 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
>             Fix For: 2.0.1
>
>         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.20.10#820010)

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

Reply via email to