On 07/15/2010 04:01 PM, Kerry Bonin wrote:
FWIW, we have a group here using it (the Python API) in a production
system (along with the C++ API), although they did have various
complaints, primarily around the lack of an callback model for the
messaging API.
Perhaps worth pointing out that it is now quite easy to do your own
dispatch to listeners on a per-session basis. E.g.
Receiver r;
while (session.nextReceiver(r, timeout)) {
Callback c = get_callback(r);//e.g. this method might use the
receivers name to lookup a registered callback
c(r.fetch(Duration::IMMEDIATE));
session.acknowledge();
}
A similar pattern works for python also. The benefit of this is that it
allows flexibility in how timeouts and acknowledgements work etc without
imposing a great deal of effort on the user.
I do think that what is offered out-of-the-box here so to speak can be
expanded. One of the next steps with the API is to look at a more
generic mechanism for polling/waiting for events of interest (not just
receipt of messages, but receipt of confirmations etc also). Moving past
the requirement for thread-per-session would be one goal here. I think
that work would also be a good route to defining utilities for message
dispatch.
Would be good to get feedback on any of the other complaints to see if
we can address them. (Your feedback on bugs in the past has been much
appreciated!).
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
