Below is list of possibly scenarios for making remote calls through remoting. Legend: thread blocks = --| thread returns = --> 1. synchronous call caller thread -- remoting client --| -- NETWORK -- pooled processing thread -- handler Calling thread goes through remoting client call stack till makes network call and blocks for response. The pooled processing thread will call on the handler, get the response from the handler and write it back to the network where will be picked up by the blocking caller thread. 2. asynchronous call - client side caller thread --> remoting client (worker thread) --| -- NETWORK -- pooled processing thread -- handler Calling thread makes invocation request and returns before making network invocation. Remoting client pooled thread takes invocation and makes call over the network. From here is same as case 1, but response is just thrown away. 3. asynchronous call - server side caller thread -- remoting client --| -- NETWORK -- pooled processing thread --> pooled async processing thread -- handler Calling thread goes through remoting client call stack till makes network call and blocks for response. The pooled processing thread will hand off invocation to a pooled async processing thread and will return (thus unblocking the calling thread on the client). The pooled async processing thread will call on handler, get response, and throw it away. 4. non-blocking asynchronous call caller thread -- remoting client --> -- NETWORK -- pooled processing thread -- handler Calling thread goes through remoting client call stack till makes network call where will only write to network, but not wait (block) for server response (see http://jira.jboss.com/jira/browse/JBREM-548). The pooled processing thread will call on the handler, get the response from the handler and write it back to the network. Not sure yet what will have to be done for this implementation as don't know if will be a problem with pooled processing thread sending data back to network with no one on the other side. Note: in the above scenarios, there is actually an accept thread on server that gets socket from server socket and passes onto a pooled processing thread and goes back to listening for next socket request. Have removed it from thread stack diagram to make easier to read. 1 - 3 are already available within remoting today. 4 is scheduled to be implemented. For 2 - 4, only getting request to server is covered. Getting response back to client will require callbacks. Also important to remember that remoting has one API that all the transport implementations support. In order to change that API for new desired behavior, all the transports must be able to support it (how it supports it is an implementation detail). As for sending raw data, this is possible to do on the client side by using the Client.RAW property in the invocation metadata map (which will send only the raw payload object and not wrap in InvocationRequest object). However, this will only be honored by the remoting http server (CoyoteInvoker). The other remoting servers (i.e. socket server invoker), will throw an exception when it does not get payload of type InvocationRequest. I can change the code for the other server invokers to behave like the CoyoteInvoker so can accept raw payload objects. The only issue with this is then loose all the extra remoting info stored within the remoting InvocationRequest (such as client sessiond id and subsystem). So this means that won't be able to a) have multiple handlers registered with connector as no way to determine which subsytem to route call to and b) be able to determine which client made call within handler based on InvocationRequest passed. Would also need to make sure don't use the Client.RAW when using addCallbackListener() method or will loose client session id and no way to setup callbacks on server side. When using RAW for http, currently work around this by using data from the http header to provide the client session id and subsystem. The same argument goes for server response being of type InvocationResponse, in that it contains extra metadata than can be used on the client side. However, can change the other transports to behave like the http server (in that if the request payload is not of type InvocationRequest, when will not wrap the handler's response object in a InvocationResponse). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3971367#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...