anonymous wrote : | If you are going to throw it away, why write it on the server side in the first place? Seems wasteful. | Correct, is wasteful. Is this way because was quickest way to get it done and have confidence would work correctly instead of introducing new code and execution path. Can be remedied as part of JBREM-548. anonymous wrote : | If the API is extended, surely existing transports are unaffacted, they can throw UnsupportedOperationException for any new methods, which won't be called by old user code anyway | If the API is extended, the transports need to support that change in that code base (this is the point I was making). Correct about previous versions being fine. But if add API that is not support by all transports, then defeats one of the main purposes behind remoting (which is common api regardless of how implemented in different transports). In regards to how server side works (at least for socket server invoker) you should really read http://labs.jboss.com/portal/jbossremoting/docs/guide/ch05.html#d0e1120 anonymous wrote : | It's also crucial to us that we only use a single TCP connection and concurrent requests are multiplexed over that -i.e. we don't want a socket pool as is currently the case with the socket transport. | This is controlled by clientMaxPoolSize property (see http://labs.jboss.com/portal/jbossremoting/docs/guide/ch05.html#d0e1052). If only want to allow one connection per client, then can set to 1 (although think code currently allows value greater than 1, but easy to fix that). As for blocking IO, not too difficult to update remoting so calling threads return immediately for one-way (async) calls and make it so server side throws away result before even reaching network. However, for async callbacks, this is more difficult in that more infrastructure is required as have to know how/where to make the callback and how to deliver it once there (which is what remoting callbacks are for). If you have any suggestions for improving the callback part, feel free to express them. Just remember that I need to be able to support the API/model over all the different transports. As for multiplex channel, if want to write your own, use MINA or whatever, be my guest. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3971648#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...