5 Replies Latest reply on Dec 8, 2005 2:27 PM by Scott Stark

    Callback for transport progress notification

    Philipp Meier Newbie

      I was looking for a way to implement some kind of transport progress notification. When a large amount of data being transfered in either direction (to/from the server) I'd like to register a "ProgressListener" to remoting to be informed of the amount of data transfered (like a web browser does). This can be very useful in rich clients to provide user feedback while a large amount of data is loaded. Is there any way to do this with the current implementation of jboss remoting? I assume the transports must be "hacked" to provide feedback while the data transfer occurs.

        • 1. Re: Callback for transport progress notification
          Tom Elrod Master

          There is no way to do this currently with the remoting implementation. To achieve this, would need to change the marshaller implementation to provide this feedback, as this is where the data is actually being sent over the wire.

          Would you mind submitting a feature request to Jira, our issue tracking system (http://jira.jboss.com), under the JBossRemoting project? We'll put it on out road map for a future release (but may be a while... unless you might have a few spare cycles) :)

          • 2. Re: Callback for transport progress notification
            mazz Master

            To me, this is something that should be implemented higher up in the stack.

            JBoss Remoting should handle the low level protocol communications and packet transfer - and it should do so as fast and simply as possible - implementing this type of progress bar probably introduces more complexity unnecessarily.

            If someone wants an application-level "progress bar" it should be implemented on top of, but not inside, JBoss Remoting. For example, if you have a large data set to transfer, chunk it in smaller pieces and transfer each chunk via JBoss/Remoting, each "chunk" then bumping up a portion of the progress bar.

            This is, obviously, IMO - but you asked for opinions, so there you go :-)

            • 3. Re: Callback for transport progress notification
              Tom Elrod Master

              The only problem is that if do it this way, would need to use the remoting streaming api vs sending invocation payloads (unless there is a way to break up the payload instance itself, which is probably going to be difficult to do). Using the streaming api is more difficult because would have to manually setup a stream within user code on the client for the payload. Even then, would still have to code the progress part youself as well (as the bytes are read from your stream).

              Although this would be much easier for me (as I don't have to code anything), doubt would be a practical solution for end user as would require too much work.

              • 4. Re: Callback for transport progress notification
                Philipp Meier Newbie

                There is another problem with chopping payload into serveral smaller ones: you loose the transaction boundary for the call.

                • 5. Re: Callback for transport progress notification
                  Scott Stark Master

                  The minimum change would be the ability to specify the stream implementation to use such that a subclass of remoting stream could be used, for example a JMXEventNotificationObjectOutputStream.

                  Breaking up the transport into blocks does not have to result in any loss of information about the transaction scope.