WAS Application Server Hang during stop
action taken: reviewed submitted doc.                                   
  Two of the four running threads in each Javacore are associated to    
  the pop-up window asking for user credentials:                        
    "Signal Dispatcher" TID:0x0000000111FEB600, j9thread_t:0x0000000    
    "AWT-XAWT" TID:0x0000000114BC0700, j9thread_t:0x00000001147C2060    
  If I don't provide the credentials within one minute, then I see      
  an access denied message on the console and a security message in     
  the SystemOut.log.                                                    
  The other two threads are:                                            
  1. "Attach API wait loop" J9VMThread:0x0000000010639900, j9thread_t:  
        at com/ibm/tools/attach/javaSE/IPC.waitSemaphore(Native Method  
        at com/ibm/tools/attach/javaSE/CommonDirectory.waitSemaphore    
          (CommonDirectory.java:220)                                    
        at com/ibm/tools/attach/javaSE/AttachHandler$WaitLoop.          
          waitForNotification(AttachHandler.java:329)                   
        at com/ibm/tools/attach/javaSE/AttachHandler$WaitLoop.run       
          (AttachHandler.java:396)                                      
    IZ73533 is a known problem with the Attach API, fixed in 6.0.0      
    SR8.  Fei is already at SR9 and this thread is not consuming        
    excessive cpu (according to the topdashH output), however it        
    would be useful to understand if disabling the Attach API would     
    have an impact on the problem.                                      
     IBM IZ73533: JAVA ATTACH API THREAD CAN CAUSE HIGH CPU UTILIZAT    
       https://www-304.ibm.com/support/docview.wss?uid=isg1IZ73533      
    I suggest disabling the java attach api function by setting  the    
    following as a webcontainer custom property:                        
            -Dcom.ibm.tools.attach.enable=no                                See this link for further instructions:                             
     IBM Setting webcontainer custom properties                         
     http://www-01.ibm.com/support/docview.wss?rs=180&uid=swg21284395   
  2.   "main" J9VMThread:0x0000000010411E00, j9thread_t:0x00000000      
       Java callstack:                                                  
           at java/net/PlainSocketImpl.socketAccept(Native Method)      
           at java/net/PlainSocketImpl.accept(PlainSocketImpl.java:451  
           at java/net/ServerSocket.implAccept(ServerSocket.java:464)   
           at java/net/ServerSocket.accept(ServerSocket.java:432)       
           at com/ibm/ws/management/tools/WsServerController.           
             waitForServerInit(WsServerController.java:238)             
           at com/ibm/ws/management/tools/WsServerStop.runTool          
             (WsServerStop.java:417)...                                 
  The stopServer.sh script spawns another Java process that does the    
  work. Typically when a stopserver attempt is made, a message          
  similar to this is appended to the SystemOut.log:                     
    AdminTool     A   ADMU3201I: Server stop request issued. Waiting    
        for stop status                                                 
  However, the  SystemOut.log doesn't show this message, so if the      
  suggestion in step 1 above does not yield results, I suggest          
  capturing a trace of the shutdown as  described in "collecting data   
  manually - step 3" of the Mustgather for Stop Server issues:          
   http://www-01.ibm.com/support/docview.wss?rs=180&uid=swg21201014     
  The change is to add this to the server's server.xml file:            
    startupTraceSpecification="*=info:com.ibm.ws.*=all"                 
  The -trace option can also be added to command line if                
  stopServer.sh is being used on the command line. Please let me know   
  if you have any questions about this.  Corinne                        
action plan: requeue for Matt's review.       
No comments:
Post a Comment