Jason T. Greene wrote:
> BTW, is a *JGroups* streaming API necessary here? The old AS
Farm
> service passed arbitrary sized files by sending byte[] chunks via
> RpcDispatcher calls. Worked fine. That's not quite what JBC would
> need, since FarmService read a chunk from a FileInputStream and
> passed it to JGroups; you'd want an OutputStream impl that would pass
> a chunk to JGroups when it's internal buffer reached size X.
Their could be an abstraction in JBC that does this, however we are
still missing the piece that says this message needs to go across a
separate p2p tcp connection. Otherwise state transfer traffic will
compete with live standard operations.
I don't think that's a problem, because most traffic in JBC is multicast
unless I'm mistaken.
Anyway, whether you use a separate channel, or reuse the existing
channel doesn't matter because at the end of the day, all traffic uses
the same underlying link to/from the switch. Even if you created a
separate connnection (like with STREAMING_STATE_TRANSFER, which creates
a separate TCP connection), this wouldn't make a difference.
This problem is amplified when we have multiple state transfers going
on.
I suppose we could dynamically create a new JGroups channel for this,
but it seems like a lot of overhead for a single p2p connection.
Yes, I wouldn't do this
--
Bela Ban
Lead JGroups / Clustering Team
JBoss - a division of Red Hat