"jahlborn" wrote : the choice made in the remoting impls leads to some performance consequences. every remote retrieval operation for inputstream requires two remote calls (hasNext and next). additionally, for the collection based impls (IteratorObjectSource), every object retrieval requires two remote calls! Ah, but the secret here is that you don't make a network round-trip for each method call. Every time an item or a batch of items is sent, an indicator can easily be added to signify that there are more items (or not). This is because each stream handler has its own wire implementation. So it's actually more efficient than RPC-style invocations (in the spirit of Remoting 3 in general, which seeks to move away from the RPC style). Not only does this mean that you don't make the extra remote request for "hasNext", but you can actually have higher throughput overall since the stream handler can forward multiple objects at one time rather than making a round trip for each one. "jahlborn" wrote : the other big thing that stuck out to me is the lack of any idempotent guarantees. it's possible this is provided by the underlying framework, but, if not, it's a significant weakness. Yes, the idea is that reliability is provided by the framework, and the user need not worry about it. If a request fails irreparably, a RemotingException is thrown. "jahlborn" wrote : another problem that's more related to remoting as a whole (at least in previous remoting versions), is the lack of an interface similar to java.rmi.server.Unreferenced. this becomes more important for things like streams which can be holding system resources which are relatively scarce (open file handles, database connections, etc). it's not uncommon for a client to die unexpectedly before the "close" method is invoked on the server. this will leave the stream resource open indefinitely. This is up to the individual stream handlers, however for the default stream handlers the close() method will be called when the remote side either (a) closes the stream explicitly or (b) lets it die unreferenced while still open. It is possible that there is a use case to handle these situations differently, but so far I know of no such case. "jahlborn" wrote : one last minor point is that i see no support for duplicate close calls (again, this could be managed elsewhere by the underlying framework). Every usage of close() uses the java.io.Closeable interface, which specifies that "If the stream is already closed then invoking this method has no effect". I do intend to keep those semantics. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4102333#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...