"trustin" wrote : We could provide both interruptable and uninterruptable invocation methods; invoke and invokeUninterruptably (or invoke and invokeInterruptably) Then user could choose what they want. Yeah, that's an option (d). I was hesitant to mention that due to the potential for massive API clutter, but that is an option as well. "trustin" wrote : What confuses me though is if we are talking about the InterruptedException raised by Thread.interrupt() or any other interruption caused by means such as cancellation request for the invocation. Or are they treated as the same thing? Do we need to discriminate these two cases? We're talking about Thread.interrupt() on the local side's blocking thread. If an operation is cancelled or interrupted on the remote side, it will get a RemotingException on the local side. The reason for this is that the proper behavior for an thread that catches InterruptedException is to either handle the interruption (if you are the owner of the thread), or propagate it. And I wouldn't want to falsely propagate thread interruption if I'm not in control of the thread's interruption policy. Does that make sense? "trustin" wrote : I'd prefer to have a subclass of RemotingException (e.g. CancelledInvocationException) if we need discrimination. Users can deal with the interruption when they really want to do. This will also help users to find out if its interrupted by Thread.interrupt(), any system signal or request for cancellation from the type of the raised exception. There is a well-defined protocol for how interruption must be handled (check out http://jcip.net/ for more info). For interruption, our two options are to throw InterruptedException, or propagate the thread's interruption flag. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4085552#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...