Hi Alex, This discussion is independent of the transport; that is, it applies equally well to the socket transport, for example. Here's an abstraction of the behavior for the case of a synchronous invocation. 1. The application calls Client.invoke(). 2. The client side of the transport marshals the invocation to the network and waits for the result. 3. The server side of the transport unmarshals the invocation and passes it the application's ServerInvocationHandler. 4. The ServerInvocationHandler returns a result. 5. The server side of the transport marshals the result to the network. 6. The client side of the transport unmarshals the result and returns it. 7. Client.invoke() returns the result to the application. Now, suppose that the client gets disconnected sometime after step 2. The ServerInvocationHandler would, by default, have no way of knowing of the connection failure, it would return its result, and the transport would fail in step 5, throwing an exception. However, Remoting does have a way of informing the application on the server side of connection failures by way of the Lease mechanism, in which a connection is continuously checked at some configured rate. Please see Chapter 8, "Connection Exception Listeners and Leasing" of the Remoting documentation at http://labs.jboss.com/portal/jbossremoting/docs/guide/ch08.html for more information about setting up leasing. When leasing is enabled on the server and the client requests leasing for a connection, then the org.jboss.remoting.ConnectionListener registered with the server by a call to Connector.addConnectionListener() will be informed if that connection has failed. The ConnectionListener could then take whatever steps are appropriate to the application, including, for example, attempting to return the result at a later time. The idea of returning the result at a later time leads us to the general possibility of asynchronous processing and callbacks. Remoting supports the ability of the server to send information to the client, independent of any particular invocation. Briefly, the application registers an InvokerCallbackHandler on the client side with a call to Client.addListener(), and, on the server side, the ServerInvocationHandler is informed of the existence of the InvokerCallbackHandler by a call to ServerInvocationHandler.addListener(), which passes in a server side "proxy" of the InvokerCallbackHandler. The ServerInvocationHandler can pass information to the client at any time by calling handleCallback() on the proxy. Callbacks could be used with or without the ConnectionListener. For example, in the case of a synchronous invocation, the ServerInvocationHandler could cache the result and, if informed by the ConnectionListener of a connection failure, it could attempt to deliver the result as a callback. Or, the application could be designed to return all result asynchronously by callback. In either case, when the ServerInvocationHandler calls InvokerCallbackHandler.handleCallback() (which is analogous to Client.invoke()), it will be informed, by catching an exception, of the failure to return a callback and it can reschedule the callback for a later time. I've omitted other modes of using callbacks, e.g., pull callbacks. For more information, see section 5.6 "Callbacks" of the Remoting documentation: http://labs.jboss.com/portal/jbossremoting/docs/guide/ch05.html#d0e2609 By the way, if you investigate further and want to submit an example of failure handling, it would be appreciated. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4023495#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...