Friday, September 7, 2012

WAS Application Server Hang during stop

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