Thanks for reviewing this.
*+ Receiver rcvr = session.createReceiver();
*What is the above call for? Is it just creating a Receiver handle for passing in to nextReceiver? If so this seems like a confusing pattern that diverges from the API it is wrapping.
The managed object, Receiver, cannot contain an actual ::qpid::messaging::Receiver, only a pointer to one. The freshly-added function createReceiver() with no args returns a managed Receiver with the pointer to a C++ Receiver that is simply allocated from the heap but not related to the Session.
*+ msg = rcvr.fetch(DurationConstants.SECOND);
*The point of the nextReceiver() call is that the receiver returned (if any) is guaranteed to have a message available. Therefore this second level of timeout on the fetch is unnecessary.
Can you trust the client not to be doing get() or fetch(), or to be running two callback servers on the same session so that the getNext returns but by the time the fetch gets there the message is gone? If there's a performance issue of adding the timer, or if the fetch throws if there's no message available then this can easily be changed. To do the fetch with a FOREVER seems dangerous.
*My instinct is that there may be some evolution in the area this Jira is aimed at as the underlying c++ client implementation is extended to support more flexible event driven patterns. (I'd also point out that the amount of code required fr the dispatch as you have proposed is pretty small).
Absolutely! The example code was designed to illustrate how easy it is to generate a callback from the current c++ client implementation. Raising a general event will require more careful analysis and possible changes to the c++ client. The c++ client and the binding will evolve together.