So, then, what would be the rest of the new client-side behavior? ? Can I queue, say, a million messages locally? ? Can I manipulate the local queue to give undelivered messages some priority? ? Will there be alternate connections to try? ? Are the queued messages persistent with a local on-disk store?
Are you trying to be a "broker" and not a "client"? Maybe you can refactor your app to have a client and a broker on the local system. Now your client can be connected to localhost while the broker does what brokers do. I can see and agree with a change to the initial connection failure case. Are you looking for more than that? -Chuck ----- "Daniel Lundin" <[email protected]> wrote: > From: "Daniel Lundin" <[email protected]> > To: [email protected] > Sent: Wednesday, December 15, 2010 9:35:32 AM GMT -05:00 US/Canada Eastern > Subject: Re: A criticism of the new messaging API > > 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] --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
