qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Ross <jr...@redhat.com>
Subject Re: A criticism of the new messaging API
Date Wed, 15 Dec 2010 16:46:13 GMT
I am interested in more.  A client API with some of the features of a 
broker would be a major help to me.

In a previous version of my app, I used the old messaging API, and since 
it didn't have reconnect, I had to write my own.  I also wrote my own 
local queueing.

I was initially optimistic that I could drop all of that with the new API, 
but it's not so clear now.

I'd like to know how many folks are going to write apps like mine, and are 
therefore going to implement their own local queueing.  Indeed, having 
folks write their own may or may not be a bad thing.  I'd like to test 
that proposition.

As to using a local broker, that may be the way to go, but it introduces 
another component into my deployment scheme, which is unattractive.  My 
app doesn't need heightened reliability (such as persistence would offer), 
so a somewhat weaker notion of queueing would work for me.

Justin

On Wed, 15 Dec 2010, Chuck Rolke wrote:

> 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