Agreed. Initial failure shouldn't be a special case. It's just a regular failure.
/d On Wed, Dec 15, 2010 at 3:31 PM, Ted Ross <[email protected]> wrote: > +1 > > The reconnect feature is major improvement over the original API but it only > works *after* a connection has been successfully established. It's very > useful for an application to start without being able to immediately > establish a connection to the broker. > > -Ted > > > On 12/14/2010 06:25 PM, Justin Ross wrote: >> >> I've recently spent some time using the new API. I'm a big fan, but I >> have a problem. >> >> My app involves multiple long-lived server components in occasional >> communication. In general, the components should start and keep running >> whether or not the broker they use to communicate is up. >> >> The API does a good job of recovering from dropped connections, but it >> doesn't really support a model where disconnection is normal and expected. >> It makes it hard for me to forget about the operational details of >> communication. See QPID-2978 and QPID-2937. >> >> To take a strong position (and therefore solicit strong feedback!): >> >> The API has a connection bias, and it's a poor fit for distributed apps >> like mine. It would be better to make local queuing primary and connection >> state secondary. >> >> Justin >> >> --------------------------------------------------------------------- >> Apache Qpid - AMQP Messaging Implementation >> Project: http://qpid.apache.org >> Use/Interact: mailto:[email protected] >> > > > --------------------------------------------------------------------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:[email protected] > > --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
