5 Replies Latest reply on Jun 24, 2005 7:13 AM by Nick Betteridge

    Streaming support - use cases?

    Tom Elrod Master

      I am working on adding support of adding the ability to send InputStreams via remoting. I have the basics working, but am struggling with how to expose this via the API.

      The concept is that if a user wants to pass any InputStream type to the server, the remoting framework will keep a reference to that stream on the client side and create a server component wrapped around that InputStream. Then will call on the server side to let it know it has an InputStream available and create a proxy on the server side to that InputStream on the client (which calls back on the server component created). The user handler on the server side is just given that InputStream proxy, which is typed as an InputStream so can call on it as though it was a local InputStream. I have all this working.

      So now onto the questions.

      1. Requirements for accessing the client over the network. Right now, the requirement would be that the server MUST be able to make calls directly to the client in order to reach that callback component for the client's stream. I don't see any other way to do this at the moment. Is this an acceptable requirement?

      2. What should the client API for this call look like? I would prefer to make this a seperate method within the Client class (i.e. stream(InputStream stream)). This makes it much easier to process because I know I am dealing with a stream explicitly. The only problem is just sending an InputStream to the server handler does not provide much context as to what to do with it. Also requires the user code on the client to know it is sending an InputStream (which I feel comfortable with as a requirement).

      The other way to do this would be to just call on the existing invoke(Object param) method and pass the InputStream as the param. This is easier from the client coding side, but will require a check on the param to see if it is of type InputStream (so extra overhead which is probably not often needed). Then under the covers, can process it as would the stream(InputStream stream) method.

      Once again, still have the problem of the server handler just getting the stream without any context as what to do with it. So another, more difficult option, would be to inspect the entire object graph for any param passed in the invoker(Object param) method and try to see if it contains an InputStream at any level and handle it. This option is almost impossible because even if can find that one of the object reference within one of the member variables of param object is of type InputStream, can not be sure that I will be able to remove it and replace with the wrapper. The only way I can think to do this is to use AOP and would then not make it into the next release of remoting.

      3. When to close the stream? My idea was to wait till the server handler called close() on the stream proxy and then close it on the client side. Only problem is in the case there is some sort of network error where the server can not reach the client and the client's real InputStream never gets closed. Should there be some sort of timeout based around this?

      Please provide any input you might have on this and will try to get this knocked out within the next week for the remoting release.

        • 1. Re: Streaming support - use cases?
          mazz Master

           

          1. Requirements for accessing the client over the network. Right now, the requirement would be that the server MUST be able to make calls directly to the client in order to reach that callback component for the client's stream. I don't see any other way to do this at the moment. Is this an acceptable requirement?


          Does this mean if I want to stream data, that means I have to have a socket open on my client side? Not desireable. Maybe I misunderstand what you are saying.

          As for the API, can't you just overload invoke() with an invoke(InputStream) and let the compiler take care of it?

          • 2. Re: Streaming support - use cases?
            Tom Elrod Master

             

            "mazz@jboss.com" wrote:
            1. Requirements for accessing the client over the network. Right now, the requirement would be that the server MUST be able to make calls directly to the client in order to reach that callback component for the client's stream. I don't see any other way to do this at the moment. Is this an acceptable requirement?


            Does this mean if I want to stream data, that means I have to have a socket open on my client side? Not desireable. Maybe I misunderstand what you are saying.


            Yes. Is the only way I can think of so that when the server handler calls the read() method on the server side, I can call back on the client to execute the read() method on the actual stream object on the client. Let me know if you can think of another way to do this. When the UIL2 type transport is done, that will call will back over the same socket the client called on, so won't be an issue (but that is a ways off, so don't want to wait for it at this point).


            As for the API, can't you just overload invoke() with an invoke(InputStream) and let the compiler take care of it?


            That works. Only issue would be context of the call. Just not sure if server side will know what to do with the stream. If user codes so that does same thing with every stream that comes in, then is fine. Just didn't know if would want to have any other data attached with the call (but guess that can be done via metadata passed if have to).

            • 3. Re: Streaming support - use cases?
              Tom Elrod Master

              Ok. Is done and checked into HEAD of JBossRemoting. See http://wiki.jboss.org/wiki/Wiki.jsp?page=Remoting_streams for details.

              • 4. Re: Streaming support - use cases?
                Nick Betteridge Newbie

                Just caught up with the streaming implementation - just what we need.

                However, one thing I'm not too sure on how to tackle is where there is a 'command' handler and the stream handler. For instance, say I wanted to implement a simple filesystem, most of the commands and data (list directory, file.exists() etc) are handled via the command handler and then the actual filetransfer is handled via the stream handler.

                Perhaps this is more of a general question on how to get the client to target different handlers on the same server.

                • 5. Re: Streaming support - use cases?
                  Nick Betteridge Newbie

                  Oops - just re-read the streaming example/sample and the standard invoke(InvocationRequest invocation) is there too.

                  ... apologies for the post