On 06/30/2011 03:49 PM, Darryl L. Pierce wrote:
On Thu, Jun 30, 2011 at 03:05:52PM +0100, Alan Conway wrote:
I'd like to see something like:
- a thread safe "get next event" call that returns events for
message delivery, async responses and any other triggers coming from
the broker
I definitely like the sound of this.
- a file descriptor that is readable whenever there are qpid events
pending so you can knit this into a poll/epoll/select loop
- an ease-of-use layer that provides ready-made thread pool
implementations of common dispatch policies e.g. message listeners,
thread-per-connection, thread-per-session, thread-per-message etc.
The ruby integration would use the lower level event handling API to
dispatch qpid events in ruby threads in whatever way is appropriate
and avoid blocking calls entirely. Obviously we're not there yet
but I think we will eventually move in that direction.
Given that I'm still fairly new to the team, how far off does that seem
on our roadmap?
I would like to make some progress on this in the Qpid 0.14 timescale.
Being API related it will likely take a bit of discussion to arrive at
something stable so I wouldn't count on anything solid appearing in the
very short term.
We should at least make a start though. It has come up in numerous
different contexts (Cliff has indicated that without this WCF couldn't
be efficiently implemented on top of the messaging API requiring it to
use internal mechanisms; Kerry raised the issue with polling in a thread
on failover notification yesterday; etc etc).
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
