All Things WebSphere

WebSphere ESI is a static and dynamic cache at the edge of the network. This cache resides in the WebSphere Proxy or the WebSphere plugin. The cache is managed by the Dynacache component of the WebSphere Applications Server. For details of how to configure ESI caching, refer to the “Configuring Edge SideInclude caching” section in the WebSphere Application Server Information Center.

ESI can cache static as well as dynamic content:

• Static caching with ESI: Well explained here: http://www.ibm.com/developerworks/websphere/techjournal/0405_hines/0405_hines.html All the static content of WAS(images, javascript, pdf's) is cached in the Plugin ESI cache if static caching is enabled.  
• Dynamic caching with ESI: All the includes in the JSP/Servlet/JSF are replaced with esi:includes that are fluffed up and cached by the WebSphere plugin ESI cache.The ESI cache can contain whole pages or fragments. It will dynamically assemble Web pages containing ESI tags from your existing application. 

The ESI cache (static and dynamic) in the WebSphere plugin or the WebSphere proxy can be monitored and administered using the WebSphere Cache monitor. ESI Cache statistics can been viewed in the cache monitor. The DynaCacheEsi.ear application along with the plugin/proxy is responsible for maintaining the backend communication channel for invalidating the cache. This application MUST be installed for cache content in the ESI cache to remain fresh i.e. for items to expire and to be invalidated by WebSphere Application Server. Once the ESIInvalidationMonitor plugin-cfg.xml property is set to true (for invalidations flow back to the ESI processor), then a long-running connection is maintained from each process to the ESIInvalidatorServlet in each application server cluster.

Plugin/Proxy-WAS interaction on the long running thread
On the first request to the plugin for a particular app server virtual host, the plugin checks to see if a connection has been made to the ESIInvalidatorServlet and if not establishes a long running connection to that particular virtual host. Therefore if the plugin is communicating with the app. server on the http and https ports then each webserver plugin process will establish 2 ESI connections to the app. server. If there are 6 web server plugin processes then there are correspondingly 12 ESI connections to the application Server. Each long running connection runs/blocks a webcontainer thread on app. server and therefore "hung thread" messages for webcontainer threads appear in the SystemOut.log when ESI is enabled.

- The The ESIProcessor WebContainer thread will only be reported once time as being hung. Once the thread is flagged as hung it is not checked again and never reported again. However, if the thread was returned to the pool and reused its status would be reset and be subject to being reported as hung again.
- Every 45 seconds the ESIProcessor webcontainer thread requests the webserver's PID and then reads on the input data stream. The read will either return the webserver's response or an exception. There is no timeout of the read. If the connection is up a response will be return, if not, an IOException occurs and the long running connection is torn down releasing the webcontainer thread.

Read more about configuring ESI and Dynacache here