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" <[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]
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
