3 Replies Latest reply on Mar 11, 2005 9:44 PM by Ben Wang

    Inconsistent handling of group rpc call exceptions

    Scott Stark Master

      I'm looking into some inconsistent behavior regarding group rpc calls and exceptions related to this bug report:

      Logging of cluster rpc method exceptions at warn level is incorrect

      One issue is that the jgroups rpc semantics with regard to exception is ambiguous in my view and I started a forum thread on that here:

      The next level of problem is that the HAPartitionImpl override of the RpcDispatcher.handle method changes the return value semantics to not include checked exceptions that may be thrown by the invocation. Only Error and RuntimeException are thrown, but these can be the normal result of the reflected method invocation, so effectively we are filtering the exceptions down to these types. Checked exceptions are simply logged as warnings and a Throwable is logged at info level.

      The cvs annotations only show that Sacha has touched this code so this is the state of this implementation from its beginning. I want to change this code to propagate all exceptions back as the return value as is done by the RpcDispatcher. Its then up to the caller of the group rpc method to figure out what to do with the heterogenous collection of normal return values and exceptions. The ha-jndi usecase which initiated this investigation simply ignores nulls and Exceptions currently. This would mean that Throwables and Errors can start showing up as the result of a lookup, so this could be a non-transparent change in behavior.

      The current behavior seems sufficiently broken to warrant this in my view. Short of actually changing the jgroups implementation, are there any other suggestions to clean this up?