Callback for transport progress notification

[llucifer]

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.

[tom.elrod]

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) :)

[mazz]

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 :-)

[tom.elrod]

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.

[llucifer]

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

[starksm64]

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.