WSRP Error Handling and InvalidSessionException

Friday, July 18, 2008

A common use case for interceptors in the WebLogic Portal framework is error handling. Using an interceptor allows a developer to trap error messages and display a more appropriate message to the end user while logging the error. The WebLogic Portal documentation contains an example of an error handler that can be found here http://e-docs.bea.com/wlp/docs100/federation/Chap-Interceptors.html#wp1031141.

There are two problems with that example though that developers should be aware of. First, the implementation shown is just an example and is thus somewhat naive. Specifically the example always returns HANDLED for faults and IO failures and thus never retries the request. In a production system under load where glitches do occur from time to time, eliminating all retries is not optimal and should be dealt with more intelligently.

The second issue is that there is one exception in particular that should be handled differently, this is com.bea.wsrp.faults.InvalidSessionException. This exception can occur when the producer session is missing some key information and typically is raised when the producer does not have the necessary templates from the consumer to format URLs. This can happen for a variety of reasons, such as fail over however the key point to understand is that Portal will automatically and seamlessly send a second request with the missing information. Thus the user never sees that an error occurred when this exception occurs.

So now that we have a grounding in InvalidSessionException, what does it have to do with error handling interceptors? The problem with this exception is that it is passed as a fault to interceptors just like any other fault. However, if the interceptor treats it as a normal fault and returns RETRY or HANDLED Portal will not send a new request with the missing information. In the case of HANDLED, no second request is sent while in the case of RETRY the original request is resent The only return value that causes Portal to deal with this fault correctly is CONTINUE_CHAIN.

Thus if you are writing an interceptor that handles faults it is highly recommend that you check the type of the Throwable being passed and if it is InvalidSessionException just return CONTINUE_CHAIN. Here is an example for an interceptor implementation of IBlockingInteractionInterceptor:

public OnFault onFault(IBlockingInteractionRequestContext requestCtx,
        IBlockingInteractionResponseContext responseCtx, Throwable t) {

    if (t instanceof InvalidSessionException) {
        if (LOGGER.isInfoEnabled()) {
            LOGGER.info("IvalidSessionException was generated and chain continued");
        }
        return OnFault.CONTINUE_CHAIN;
    }
    //.. rest of error handler here
}

I do have a support case open for this issue as this strikes me as a bit of a bug, developers should not have to code special handling for situations like this and RETRY should be considered semantically equivalent to CONTINUE_CHAIN for this situation in my opinion.

Posted by Gerald Nunn at 9:43 AM | Categories: WebLogic | Permalink