Streaming in R3

[trustin]

IIUC, we create a new connection to pull data from a stream in R2 and close the connection when we reach to the end of the stream, right?

If so, I think it might cause a problem when a user exchanges thousands of small stream objects because of too many TIME_WAIT state and the cost of creating and destroying a connection. We already have a plan to support multi-channel communication in R3, so I think we should use that facility unless the client is R2. WDYT?

[dmlloyd]

In R2 there is a new connection, but it does not support more than one stream per request in any case.

In R3 we definitely will use a multichannel facility if it is available (SSH). I plan to use an XNIO ChannelSource to produce channels for R3 streams - the implementation could just create a separate connection but the intent is to use multiplexing whenever it is available.

[trustin]

It's a good idea to reuse a particular number of dedicated connection(s) to transfer streams.

On the other hand, we will have to split a stream into small chunks to assure minimum QoS of streaming more than one stream with one connection. And then we could fulfill a possible use case that requires no more than one connection.

[dmlloyd]

Yeah, the ChannelSource can implement pooling if needed. In terms of QoS... I think that is up to the transport. Sockets for example are handled by the OS of course. Other transports specify how bandwidth is shared as well. I think it should be up to the channel implementation to keep stream handlers as simple as possible.

[ron_sigal]

By the way, I'm not aware of any JBoss code that uses Remoting streaming, so maintaining streaming compatibility between Remoting 2 and 3 may not be of the highest priority.

[starksm64]

There are two pieces of code in jbossas that use the streaming function to transfer deployment archives to the server.

[dmlloyd]

Hm, nevertheless that's an interesting point. Compatibility is a bit more straightforward if we can disregard the old streaming stuff I think.