qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: proton Messenger error handling/recovery REQUEST FEEDBACK!
Date Tue, 09 Sep 2014 15:17:24 GMT
On 09/09/2014 03:59 PM, Alan Conway wrote:
> On Mon, 2014-09-08 at 19:07 +0100, Fraser Adams wrote:
>> Messenger gurus seem to be keeping their heads down a bit.
>> Is it *really* just Alan and I who are interested to understand the
>> error handling/reconnection behaviour of Messenger?
>> Is anybody using it in "industrial strength" applications or is it just
>> being used in quick and dirty demos? Without error handling and
>> reconnection mechanisms I'm struggling to see how it can be used for the
>> former.
>> I can likely hack things and Alan also mentioned that he "cheats", but
>> I'd really like to know from people who really understand messenger how
>> to do it *properly*.
> I've been looking at this and error handling in Messenger is not just a
> matter of fixing implementation, there are some pretty big API questions
> to be answered about when and how you can report errors. Its not
> unfixable but I'm starting to think about moving away from Messenger and
> towards using the proton Engine API.
> The original tradeoff was that engine is more complete and flexible but
> harder to use, whereas Messenger is easy but not as complete/flexible.
> However if you look at the toolkit & examples at
>   https://github.com/grs/examples
> it makes engine a lot more appealing.

This work has now been moved to a branch in proton's svn:


examples themselves are in:


I'm working on a slightly more involved example at the moment which I'll 
hopefully be in a position to check in before too long.

I should also point out again that these examples originated from Rafi's 
demo of the event oriented use of proton 
(https://github.com/rhs/qpid-proton-demo) which also show how features 
such as those offered by Messenger (routing, connection management) can 
be built as more composable utilities along the lines Alan describes below.

> The idea is to provide blocks of
> "normal default" behavior in a toolkit to get going quickly (and to keep
> you going for many/most uses) but allow those to be modified or replaced
> as things get more complex. The nice thing about this is that you know
> you can peel back the toolkit if you need to and get full access to the
> proton event machine, so anything proton knows you can react to.
> If we can make the engine API approachable enough for general messaging
> use (while keeping it powerful enough for integration use) then it might
> make more sense to focus on doing that than on maintaining two different
> APIs for proton.

I very much believe it would.

To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

View raw message