Andrew Stitcher wrote:
On Fri, 2009-12-11 at 22:18 +0000, Robert Greig wrote:
2009/12/11 Alan Conway <[email protected]>:
Currently the assumption of CPG is baked into qpidd but in principle we
could abstract the virtual synchrony layer and allow other another VS engine
to plug in. I've only worked with CPG to date so I don't have a good handle
on how big are the API differences might be so hard to say how much work it
would be.
I think it would be useful - certainly if I were trying to sell Qpid
derivatives commercially I would be looking at something that didn't
require multicast (or RDMA for that matter). I don't know if multicast
is on the EC2 roadmap but I certainly can't imagine that RDMA is. The
latency is important for some users but for others the throughput is
more important (along with easy hosting on services such as EC2).
Just for clarity, there is no necessity for RDMA in any qpid deployment
scenario. Specifically RDMA and clustering are not connected as far as
qpid is concerned. I believe that running AIS on top of RDMA may be a
possibility, but that is opaque/transparent (pick your preferred
metaphor) to qpid itself.
Of course if you want to use RDMA as a transport for the "manifest
goodness" (tm) that it brings you can.
What I was talking about is that AIS/corosync has added support for RDMA
& thus now also
handles for non UDP transports. So if we want to add options for
clustering (CPG) other than
UDP then adding them to AIS/ corosync is probably better than doing so
via the Qpid code base.
Carl.
