Esteve,
Thanks for your reply.
Esteve Fernandez wrote:
- Implement AMQP using an asynchronous library, in this case ASIO is the
perfect candidate, as it will be part of C++0x
I like the idea of ASIO, however it still isn't clear to me how an
existing single-thread select() based Reactor pattern can be refactored
to use it easily. Perhaps I just need to look at Boost harder.
- Implement client and server asynchronous transports for Thrift (using ASIO).
Have a look at the standard framed transport (TFramedTransport).
Seen.
- Make the Thrift compiler generate client functions which return Deferreds
(futures) instead of real values. Also, you'll have to add some code in the
server for supporting asynchronous handler functions. Given that there will be
support for futures in C++0x, you won't need to roll your own version.
I wasn't aware that the Thrift compiler would need modified in this way;
thank you for pointing this out. Yes, XRLs are fully asynchronous, so
any replacement has to be also.
I assume you mean futures as an abstract concept here, and not as a part
of Boost or indeed C++0x.
The support for futures in C++0x struck me as very limited, especially
the lack of composability.
I took a look at the Boost.Future library. It does not yet appear to
have been accepted for Boost, it is not in 1.37.0 (FreeBSD ports) or
1.39.0 (currently in testing). I have concerns about Boost.Future as a
mechanism anyway. Braddock Gaskill pointed out in the documentation that
the futures 'cancel' functionality has been deprecated.
Whilst it abstracts away some of the thread and/or atomic glue that is
needed when threads are actually used, I'm concerned that it's just more
obfuscation in the XORP case -- XORP uses co-routines in a single
thread, explicitly invoked from the EventLoop, it does not use
continuations in the fully fledged sense of that word, so the thread
pool guards which Futures would likely bring in, wouldn't be needed to
begin with when Thrifting XORP.
We deliberately avoided introducing threading into the XORP code base
for many years for just these reasons -- C++ threading is still not
ready for prime time, although the efforts ongoing are almost, almost there.
Replacing the XRL mechanism is moderate risk. Thrift doesn't have a
broker; a broker is needed in our case. Given the engineering effort
which would be involved in implementing AMQP, I don't think we can rely
on AMQP alone as the broker, so an intermediate mechanism is required.
- Glue them together using a TMemoryBuffer, a special transport (e.g.
TwistedAMQPTransport in txAMQP) and the "reply-to" property in AMQP
Aside: I see reply-to is still TODO in the AMQP 1.0 draft.
I guess you are working against the AMQP 0.8 spec?
I updated the RabbitMQ port for FreeBSD to 1.6.0 this week. I ran the
Qpid Python test suite against the broker, and got the same results as
LShift's engineering team have published.
P.S. Tony from LShift has an experimental C client for RabbitMQ in the
works.
Hope that helped, feel free to ask any details if you need more info.
BTW, here are the slides from the talk I gave at PyCon (and which I'll give at
EuroPython too) about Thrift, AMQP and Twisted:
Already digested. Nice work.
The Thrift ASIO story probably needs to be clearer first before we could
proceed with AMQP in C++.
cheers,
BMS
