qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chuck Rolke <cro...@redhat.com>
Subject Re: A criticism of the new messaging API
Date Wed, 15 Dec 2010 16:28:00 GMT
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" <dln@eintr.org> wrote:

> From: "Daniel Lundin" <dln@eintr.org>
> To: dev@qpid.apache.org
> 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 <tross@redhat.com> 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:dev-subscribe@qpid.apache.org
> >>
> >
> >
> >
> ---------------------------------------------------------------------
> > Apache Qpid - AMQP Messaging Implementation
> > Project:      http://qpid.apache.org
> > Use/Interact: mailto:dev-subscribe@qpid.apache.org
> >
> >
> 
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project:      http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org


Mime
View raw message