Keeping it simple, I would like to be able to create a connection with
reconnect enabled, a session, a sender (with a capacity) and be able to
produce up to <capacity> messages with the connection never having been
established.
-Ted
On 12/15/2010 11:46 AM, Justin Ross wrote:
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]
