Inconsistent handling of group rpc call exceptions

[starksm64]

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

http://jira.jboss.com/jira/browse/JBAS-1571
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:
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3869760

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?

[bill.burke]

I'm pretty sure I implemented this stuff long ago, but I can't remember why I was eating exceptions.

[ivelin.ivanov]

I think this suggested behavior is an improvement.

ha-jndi should be using jbosscache to guarantee transactional state replication, so that either all or no objects are bound.

A future task that would be useful is to offer higher level transactional rpc calls. So that 1) the code throwing the exceptions can participate in the decision whether or not it affects the overall call; 2) the originating caller can roll back the effect of the call based on the outcome.

Ivelin

[ben.wang]

Transactional jndi state replication can be achieved with JBossCache now. Transactional rpc will need work though. But I like the idea. I can put this in the roadmap.

-Ben