PM28289: HIGH CPU USAGE ON A CLUSTER NODE.

7.0.0.17: Java SDK 1.6 SR9 FP1 Cumulative Fix for WebSphere Application Server
7.0.0.27: Java SDK 1.6 SR13 FP2 Cumulative Fix for WebSphere Application Server
7.0.0.19: Java SDK 1.6 SR9 FP2 Cumulative Fix for WebSphere Application Server
7.0.0.21: Java SDK 1.6 SR9 FP2 Cumulative Fix for WebSphere
7.0.0.23: Java SDK 1.6 SR10 FP1 Cumulative Fix for WebSphere
7.0.0.25: Java SDK 1.6 SR11 Cumulative Fix for WebSphere Application Server
7.0.0.27: Java SDK 1.6 SR12 Cumulative Fix for WebSphere Application Server
7.0.0.29: Java SDK 1.6 SR13 FP2 Cumulative Fix for WebSphere Application Server
7.0.0.45: Java SDK 1.6 SR16 FP60 Cumulative Fix for WebSphere Application Server
7.0.0.31: Java SDK 1.6 SR15 Cumulative Fix for WebSphere Application Server
7.0.0.35: Java SDK 1.6 SR16 FP1 Cumulative Fix for WebSphere Application Server
7.0.0.37: Java SDK 1.6 SR16 FP3 Cumulative Fix for WebSphere Application Server
7.0.0.39: Java SDK 1.6 SR16 FP7 Cumulative Fix for WebSphere Application Server
7.0.0.41: Java SDK 1.6 SR16 FP20 Cumulative Fix for WebSphere Application Server
7.0.0.43: Java SDK 1.6 SR16 FP41 Cumulative Fix for WebSphere Application Server

APAR status

• Closed as program error.

Error description

• The stack trace for high CPU thread in this situation is:
  
  ThreadMonitor W WSVR0605W: Thread "Default : 13870" (00003697)
  has been active for 758148 milliseconds an may be hung. There
  is/are 1 thread(s) in total in the server that may be hung.
  at
  com.ibm.ws.http.channel.compression.GzipInputHandler.decompress
  (GzipInputHandler.java:381)
  at
  com.ibm.ws.http.channel.impl.HttpServiceContextImpl.moveBuffers(
  HttpServiceContextImpl.java:3630)
  at
  com.ibm.ws.http.channel.impl.HttpServiceContextImpl.readBodyBuff
  er(HttpServiceContextImpl.java:3505)
  at
  com.ibm.ws.http.channel.impl.HttpServiceContextImpl.continueRead
  (HttpServiceContextImpl.java:4425)
  at
  com.ibm.ws.http.channel.outbound.impl.HttpOSCBodyReadCallback.co
  mplete(HttpOSCBodyReadCallback.java:71)
  at
  com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureComp
  lete(AioReadCompletionListener.java:165)
  at
  com.ibm.io.async.AbstractAsyncFuture.invokeCallback(AbstractAsyn
  cFuture.java:217)
  
  And the trace shows the following infinite repetition with the
  trace string set to
  "com.ibm.ws.proxy.*=all:HTTPChannel=all:GenericBNF=all":
  
  GzipInputHand >  decompress,
  input=java.nio.DirectByteBuffer[pos=0 lim=4338 cap=4338] Entry
  GzipInputHand 3   Parsing trailer, offset=8 val=30
  GzipInputHand 3   input buffer has unused data;
  java.nio.DirectByteBuffer[pos=0 lim=4338 cap=4338]
  GzipInputHand <  decompress, output=0 Exit
  GzipInputHand >  decompress,
  input=java.nio.DirectByteBuffer[pos=0 lim=4338 cap=4338] Entry
  GzipInputHand 3   Parsing trailer, offset=8 val=30
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED:  IBM WebSphere Application Server Version    *
  *                  7.0 users.                                  *
  ****************************************************************
  * PROBLEM DESCRIPTION: The HTTP Channel can get into an        *
  *                      infinite loop while decompressing data  *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  When decompressing data the HTTP Channel can get stuck in an
  infinite loop. This occurs because the HTTP Channel
  automatically does a read instead of notifying the user code a
  read has to be done. This, in turn, causes the decompression
  methods to think it's already done and continually loop. With
  the following trace string set the problem could be seen:
  "com.ibm.ws.proxy.*=all:HTTPChannel=all:GenericBNF=all":
  GzipInputHand > decompress,
  input=java.nio.DirectByteBufferpos=0 lim=4338 cap=4338 Entry
  GzipInputHand 3 Parsing trailer, offset=8 val=30
  GzipInputHand 3 input buffer has unused data;
  java.nio.DirectByteBufferpos=0 lim=4338 cap=4338
  GzipInputHand < decompress, output=0 Exit
  GzipInputHand > decompress,
  input=java.nio.DirectByteBufferpos=0 lim=4338 cap=4338 Entry
  GzipInputHand 3 Parsing trailer, offset=8 val=30
  

Problem conclusion

• The HTTP Channel was modified to notify the user code a read
  needs to be done and also properly reset the decompression
  methods so they don't think they are done
  
  The fix for this APAR is currently targeted for inclusion in
  fix pack 7.0.0.17.  Please refer to the Recommended Updates
  page for delivery information:
  http://www.ibm.com/support/docview.wss?rs=180&uid=swg27004980
  

Temporary fix

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

Fix information

• Fixed component name

  WEBS APP SERV N

• Fixed component ID

  5724H8800

Applicable component levels

• R700 PSY

     UP