Portlet considerations for parallel portlet rendering
In general, all portlets must be implemented in a thread-safe manner to be accessible by multiple users at the same time. The portlets can then easily be rendered in parallel.
However, you need to be aware of the following
specific limitations for portlets to render in parallel:
- In general, do not use any non-public APIs or APIs that are not documented for use in portlets, such as engine tags with portlets. The public APIs are defined in the WebSphere® Portal Java documentation.
- Portlets that are rendered in parallel must not access any non-threadsafe
objects that are scoped to the servlet request:
- In general, thread safety of the objects is documented in the Java documentation. Examples of non-threadsafe objects are all unsynchronized Java collections and org.apache.jetspeed.portlet.User .
- The portlet request that is passed to portlets that are rendered in parallel is threadsafe and all methods that are part of the portlet API can be safely used. However, the underlying servlet request is not threadsafe.
- Portlets that are rendered in parallel, like any other defensively implemented portlets, should be prepared to handle IOExceptions when writing to the OutputStream or PrintWriter of the PortletResponse: Depending on the configuration settings for parallel portlet rendering, if a portlet takes too much time for rendering its content, the portal can cancel rendering this portlet. When the portlet tries to write to the OutputStream or PrintWriter after the portal has canceled the rendering, this results in an IOException. In this case the behavior is the same as if the user closes the browser before the resulting page is delivered to the client. The portlet should take care of proper error handling for this situation.
- Portlets that are rendered in parallel should be prepared to stop
rendering the content:
- In methods that are expected to take many computation cycles, the portlet should check by extended intervals if the flush method of the OutputStream or PrintWriter throws an IOException. If the flush method throws such an exception, the portal has canceled rendering the portlet, and the portlet should terminate its current computation in order to reduce resource usage.
- This fault tolerant implementation is useful for various situations in which a response can no longer be delivered to the client. For example, this can happen if the network fails, or the client is closed, or the follow-on page request has already been sent or reloaded. Take care to finalize critical backend operations in order to keep back ends in a consistent state. This processing should be done in the action processing phase and not in the render phase. For the Portlet Development Guide refer to IBM developerWorks.