Troubleshooting
Problem
When the Content Engine resides on WebSphere Application Server (any supported version) and you are using the CEWS transport, you might see an intermittent problem when exceptions are being returned to the client from the Content Engine server. (This problem does not occur with EJB transport.)
Cause
In these cases, the socket for the HTTP response is prematurely closed. Depending on the exact timing of the packets arriving at the client side, this can result in an EngineRuntimeException with any of these ExceptionCode values: TRANSPORT_WSI_DESERIALIZATION_ERROR or TRANSPORT_WSI_NETWORK_ERROR. The underlying root cause exception will be an instance of java.io.IOException.
Resolving The Problem
The following workaround is provided in the release notes for P8 4.5.1:
Change the HTTP response code used by the Content Engine server when it is returning an exception. A different response code will be used if you set this Java system property in the JRE of the Content Engine server: FileNet.WSI.HttpFaultResponseCode. A value of 599 is recommended (the default value is 500). You would typically set this value via the WebSphere administrative console in the JVM parameters screen:
-DFileNet.WSI.HttpFaultResponseCode=599
This problem and workaround apply to P8 4.5.1 because the default HTTP exception response used by the Content Engine is 500 for those releases.
The problem did not apply to 4.0.1 or 4.5.0 releases because they used Systinet.
Starting with P8 5.0.0 the default HTTP response is no longer 500, so it is no longer necessary to change from the default exception response.
Was this topic helpful?
Document Information
Modified date:
17 June 2018
UID
swg21617408