On Tue, Sep 9, 2014 at 5:22 PM, Alan Conway <[email protected]> wrote: > Given that engine is already a more complete and flexible API (in the > sense of offering full low-level access to the entire AMQP protocol), > and that people are demonstrating that it can be made easier to use by > layering tools on top, perhaps that is where we should focus our efforts > rather than splitting them over two APIs.
We are using proton in production environment. We started out using the messenger API but at some point we were struggling with the fact that there is no notion of a connection in this API. This is made worse by the fact that the handling of connection failures (at least proton-j, not sure about proton-c) is not working. For us the concept of a connection is crucial in a communication API because drastic measures (from a software point of view) need to be taken if the loss of communication persists for to long a period of time. Therefore we switched to the engine API and implement our own "messenger" which in our experience was a friendly enough API and has given us what we need. So in that light I would support Alan's suggestion for focusing more on the engine API (of course this is an easy statement for us because we are not using the messenger API anymore). This would also maybe give some more time to focus on existing connection related (and other) bugs currently in the engine API such as https://issues.apache.org/jira/browse/PROTON-644 ... :) > > > >>>> I've probably missed something, but I don't know how to reliably > > > >>>> detect > > > >>>> failures and reconnect. I don't think this is possible at the moment. At least in proton-j the messenger will swallow exceptions thrown on channel.write() (indication a connection failure), will not correctly handle errors returned by channel.read() and support for detecting connection failures through idle timeout is not implemented yet in the proton-j engine API. > > > > - proton (or any library!) should NEVER EVER write anything direct to > > > > stdout or stderr. It needs a (very simple) logging facility that can > > > > write to stderr by default but can be redirected elsewhere. > > > > - proton should never log an error without also returning some useful > > > > error condition to the application. Agree, although these printfs are fairly scarse at the moment. I guess for this the pn_transport_set_tracer idea (which works well) could be extended. -- Marcel --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
