Remote Rendering portlet hangs on socketRead0()

当我们在JAVACORE文件中发现很多WEBCONTAINER挂起在INPUTSTREAM方法或SOCKETREADER方法中时，解决如下：（另有一参考在DB2类型中）

Problem(Abstract)

This technote describes a workaround when the Web Content Management Remote Rendering portlet hangs on socketRead0().

Cause

WebSphere Portal SystemOut.log shows hung Web container threads:
[14:29:40:901 EDT] 55be0ad9 ThreadMonitor W WSVR0605W: Thread "Servlet.Engine.Transports : 10" (42520adb) has been active for 709,037 milliseconds and may be hung. There are 9 threads in total in the server that may be hung.

A review of the javacores show the Web Content Management Remote Rendering portlet is hung in socketRead0():

3XMTHREADINFO "Servlet.Engine.Transports : 10" (TID:0x807A0D30, sys_thread_t:0x46D0C328, state:R, native ID:0xAFCD) prio=5
4XESTACKTRACE at java.net.SocketInputStream.socketRead0(Native Method)
4XESTACKTRACE at java.net.SocketInputStream.read(SocketInputStream.java(Compiled Code))
4XESTACKTRACE at java.io.BufferedInputStream.fill(BufferedInputStream.java(Compiled Code))
4XESTACKTRACE at java.io.BufferedInputStream.read1(BufferedInputStream.java(Compiled Code))
4XESTACKTRACE at java.io.BufferedInputStream.read(BufferedInputStream.java(Compiled Code))
4XESTACKTRACE at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java(Compiled Code))
4XESTACKTRACE at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java(Compiled Code))
4XESTACKTRACE at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java(Compiled Code))
4XESTACKTRACE at org.apache.jsp._Default.getExternalPage(_Default.java(Compiled Code))
4XESTACKTRACE at org.apache.jsp._Default.getContent(_Default.java(Compiled Code))
4XESTACKTRACE at org.apache.jsp._Default.getWCMFooter(_Default.java(Compiled Code))
4XESTACKTRACE at org.apache.jsp._Default._jspService(_Default.java(Compiled Code))
4XESTACKTRACE at com.ibm.ws.webcontainer.jsp.runtime.HttpJspBase.service(HttpJspBase.java(Compiled Code))
4XESTACKTRACE at javax.servlet.http.HttpServlet.service(HttpServlet.java(Compiled Code))
...

The Web Content Management (WCM) Remote Rendering portlet does blocking I/O when getting content from the WCM server. If the WCM server unexpectedly hangs or exits, the WCM Remote Rendering portlet may also hang in java.net.SocketInputStream.socketRead0(), and its Web container threads may never get free. The WCM Remote Rendering portlet sets no timeout on its block socket operations to the WCM server.

Restarting the WCM Remote Rendering portlet EAR (for ilwwcm-remoterendering-portlet.war) does not free the hung Web container threads.

Resolving the problem

One solution is to restart WebSphere Portal.

Another workaround is to configure the Java networking properties for java.net.URLConnection. These properties specify the default connect and read timeout (response) for the protocol handler used by java.net.URLConnection. Note this will affect all java.net.URLConnections in the JVM, not just those from the Web Content Management Remote Rendering portlet.

In the WebSphere Application Server administrative console for the Web Content Management delivery server, click Servers -> Application Servers -> <websphere_portal_name> -> Process Definition -> Java Virtual Machine -> Custom Properties. Add the following name and value pairs (for example, for a 5 minute timeout):

sun.net.client.defaultConnectTimeout=300000
sun.net.client.defaultReadTimeout=300000

Save the changes, and restart WebSphere Portal.

The Web Content Management Local Rendering portlet does not use sockets and does not have this problem. It uses a Java API in order to access the local Web Content Management content.